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An important problem arising from the increased sharing of information across 
networks is bandwidth constraint. Then limitations of communications channels in the 
transmission of volumous information is the singular bottleneck dictating processing 
capability and robustness of current and future distributed systems. Bandwidth utilization 
with the goal of optimizing the actual information transmitted, has to date, been ignored. 
Many of the current network strategies, both commercial, and tactical, rely on the 
repeated broadcast of a standardized message. As a result, much available bandwidth is 
wasted. The specific approach taken to maximize specific network node throughput on a 
digital network is a three-layer paradigm, managed by an embedded autonomous 
software agent located at each network node. The first layer consists of a network 
specific strategy for reducing the message content. The second layer is a frame by frame 
analysis of the reduced message content, to determine the best compression method to be 
applied to the information itself (MPEG, etc.). Finally a packaging strategy is utilized to 
maximize the compressed content for each specific network packet. The first phase of a 
proof of concept prototype has been implemented. Initial results, via a network 
simulation, have demonstrated a quantative 300% plus increase in effective information 
throughput capability, utilizing the same bandwidth. Since this approach is an embedded 
technique, existing network hardware, software, and standards remain uneffected. A side 
benefit witnessed is increased network responsiveness, due to increased information flow 
in a timely manner. In terms of processing time required, the cost is more than 
compensated for by increased network efficiency. The net result is a more efficient and 
responsive network capability. Future efforts will implement the entire node management 
capability described in this thesis. It is anticipated this capability will be introduced to the 


opporational fleet within the next five to seven years. 
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agent 


RTR 
C2P 


JTIDS 


CDLMS 


LIST OF ACRONYMS 


in the context of this thesis, a goal seeking, semi-intelligent, independent 
program working on behalf of a host system to increase efficiency 


real time retargeting 

command control processor 

Joint Tactical Information Distribution System, the system name for a 

spread spectrum, anti-jam, means of time synchronized, digital 
communication 

Common Datalink Management System. 


radio frequency, as in RF transmissions 


herein referes to military specific digital communications networks operating 
over a radio frequency spectrum (RF) 
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L. INTRODUCTION 


A. GENERAL 


The advent of the computer age has brought about a plenitude of benefits to the human 
race. Included with these benefits has been the ever increasing demand to transfer exponentially 
increasing amounts of information, and the associated problems of information sharing. The 
focus of this thesis, associated Naval Science Assistance Program (NSAP), and Office of Naval 
Research (ONR) funded research effort, has been to best utilize available digital communications 
assets in the radio frequency (RF) spectrum to allow sufficient transfer of information providing 
DOD assets flexible, rapid, and in-flight reprogramming, re-planning of strike and cruise missile 
assets, to engage a high value, emergent target, in the shortest possible time. The postulated 
methods of utilizing autonomous agents to manage information flow across network nodes has 


applicability to all digital networks. 


Based upon the pioneering work of Pattie Maes, at Massachusetts Institute of Technology 
(MIT) (4, 17, 31, 33, 53, 54), and previous examination of communications node management 
(37, 38), the implementation of independent processes, working on behalf of a host system, to 
optimize the effective meaningful throughput on a communications channel is not only 
desirable, but necessary. The evolution of semi intelligent software, whether called Artificial 
Intelligence, Intelligent Agents, or Autonomous Agents, has reached a level of sophistication 
allowing the insertion of meaningful articulated processes within existing, and future systems 
maximize the network efficiency systematically. Recent work by Michael Cohen on Sodabots 
(8), and the evolution of user interactive TinyMUDs (Multiple User Dimension) of the Maas- 
Neotek family (4), a virtual type personality environment, has demonstrated the ability of 
software to deal with dynamic and changing conditions. The additional, and exponential increase 
in micro-processor power has, for the first time, made available the hardware for such agent 
implementations as compact, self contained, embedded systems, in direct support of larger 


existing systems. 


B. PROBLEM STATEMENT 


At present, tactical command and control networks, such as Link 16, do not employ data 
management techniques to maximize the utilization of the RF spectrum. With respect to the 
surveillance Net Participation Group (NPG), information updates on platform tracks are 
transmitted in full and at a high rate. This is true even when only a single data field (e.g., the 
location) of the track information has changed. The rapid repetition of redundant information 1s 
a characteristic of other NPGs as well. One of the reasons for this repetition is that a listener, if 
he misses a message, can simply ignore it—another chance to receive the information will soon 
follow. An important drawback of this passive design, however, is that the bandwidth needed to 
support RTR requirements will not be available. 

It is assumed that no new tactical networks (hereinafter referred to as “links’”) will be 
available for the foreseeable future, and certainly not in time to meet the needs of the RTR 
Cruise Missile demonstration and the RTR program that supports It. 

Therefore every effort must be made to obtain more efficient use of bandwidth from 
existing links. There are five methods, independent of efforts to handle network entry, and 
passive synchronization, that this effort will explore: Atomic Data Element Transmission, 
Update Bundling, Extrapolation-Driven Updates, Traditional Compression, and Active Network 
Management. In FY96, message size reduction was demonstrated on a closed loop link 
simulation, built upon existing assets. These initial achievement are leading toward benchmark 
demonstrations utilizing NRaD’s Systems Integration Facility (SIF) to establish best-case 
effectiveness. In later years, benchmarks will be established for additional techniques. 

The ultimate aim is to increase the available bandwidth, through efficient and more 
formal management of existing tactical networks, without changing network operation rules or 
message integrity assurance. This capability will result in a new way of handling information on 
existing links, with the possibility of extending capability to a new message specification while 


coexisting within the given operational network. 


As demonstrated by the news presented every day, reactionism is ever increasing in 


today’s complicated world. The demise of the former Soviet Union has eased the potential for 


aed exchanged by responsible parties, but has dramatically increased the potential of 


stilities with the slightest trigger event leading to potential larger exchanges, and loss of life. 


A small trigger event 





leading to escalation 





leading to a larger response 


J.S. Navy Video 





all within a very short period of time. One key point to bear in mind, even the smallest have not 
organizations, or countries have access to weapons of mass destruction. The rational mindset 
does not necessarily apply here, therefor the need for rapid response dictating efficient 


communications throughput capacity. 


II. RISK ASSESSMENT FOUNDATION FOR DESIGN PRINCIPLES 


A. INTRODUCTION 


This document describes the engineering design of an autonomous or knowledge-based 
agent designed to increase effective throughput on tactical links. The agent itself is called 
“Agent,” and each instance of the agent is identical on all nodes in the network. The sole 
assumption made by the architecture is that each node on the network will have an agent 
associated with it able to intercept and manipulate both incoming and outgoing messages. 

The architecture is knowledge-based in all other respects. Thus it is not specific to any 
particular tactical link or digital network. To operate on some other network requires 
modifications to the knowledge bases and facts, but no modifications to the agent itself. 

This document is not intended to function as a tutorial for knowledge-based systems 
concepts. It assumes a high level of sophistication in traditional concepts and addresses where 
the engineering design departs from them. Neither is this document intended to be a tutorial 
about Link-16 or other tactical communications networks. 

The principal accomplishment was the design of an inference engine specifically tailored 
for intelligent agents. The special features of this inference engine are described in depth so that 
detailed designers can know what to do. 

Each process in the system is controlled by meta rules and a special meta controller that 
is part of the agent run-time environment. Although an elaborate meta language was designed, 
adding sophistication to the inference engine reduced reliance on sophisticated meta rules. Very 
few functions are involved at present. 

The run-time environment for the agent was not designed. The assumption was that one 
or More commercial agent-building tool kits, such as IBM’s ABE (Agent Building Environment) 
would be available to initialize and run the agent. Since these tool kits can be modified to use a 
custom inference engine, and because the facts and rules used by the Agent system can in 
general be translated to and from KIF, the assumption that a tool kit would be available at the 
time of detailed design seems reasonable to the author. However, there is nothing in this system 


that requires the use of such a tool kit. The run-time mechanisms necessary to control the 


processes and inferencing are not complicated. This supports an implementation structure in 
which the agent can run on its own machine inserted at each node between the node and the 
network. 

This document assumes Link-16 concepts but the methods of autonomous agents are not 


specific to Link-16. 


B. PROBLEM STATEMENT 


At present, tactical command and control networks, such as Link 16, do not employ data 
management techniques to maximize the utilization of the RF spectrum. With respect to the 
surveillance Net Participation Group (NPG), information updates on platform tracks are 
transmitted in full and at a high rate. This is true even when only a single data field (e.g., the 
location) of the track information has changed. The rapid repetition of redundant information 1s 
a characteristic of other NPGs as well. One of the reasons for this repetition is that a listener, if 
he misses a message, can simply ignore it—another chance to receive the information will soon 
follow. An important drawback of this passive design, however, is that the bandwidth needed to 
support information exchange requirements will not be available. 

It 1s assumed that no new tactical networks (hereinafter referred to as “links’’) will be 
available for the foreseeable future. 

Therefore every effort must be made to obtain more efficient use of bandwidth from 
existing links. There are five methods, independent of efforts to handle network entry, and 
passive synchronization, that this effort will explore: Atomic Data Element Transmission, 
Update Bundling, Extrapolation-Driven Updates, Traditional Compression, and Active Network 
Management. In FY96, message size reduction was demonstrated on a closed loop link 
simulation, built upon existing assets. These initial achievements are leading toward benchmark 
demonstrations utilizing Naval Research Development Test & Evaluation (NRaD) Systems 
Integration Facility (SIF) to establish best-case effectiveness. In later years, benchmarks will be 
established for additional techniques. 

The ultimate aim is to increase the available bandwidth, through efficient and more 


formal management of existing tactical networks, without changing network operation rules or 


message integrity assurance. This capability will result in a new way of handling information on 
existing links, with the possibility of extending capability to a new message specification while 


coexisting within the given operational network. 


ce. GLOBAL REAL TIME RETARGETING REQUIREMENT 


The basis for this thesis was guided by sponsor desires to support rapid mission re- 
allocation of assets in support of emergent threats on a real time basis. FY96 Program Execution 
Plan for Real-Time Retargeting (RTR) provides a good list of the general requirements for real- 
time retargeting, and basis by which the concept and development of agents is being 
accomplished: 


The ONR Real-Time Retargeting (RTR) Accelerated Capability Initiative (ACI) is aimed 
at providing the cruise missile and tactical aircraft warfighters a new capability to 
redirect their strike forces in real-time to respond to current dynamics of the battlefield. 
The focus of the ACI is on time-critical targets. To engage such targets, these 
warfighters must plan/replan, control, and execute strikes in 5 to 30 minutes, instead of 
the military’s current operational capability of many hours. Current shortfalls that inhibit 
these warfighters from responding in real-time are: (1) lack of automated real-time 
mission (re)planning capability, (2) lack of communications availability and capacity, (3) 
lack of automated target detection and recognition, (4) lack of rapid mission management 
and execution decision aids, (5) lack of real-time terminal targeting information 
dissemination between surveillance assets and strike platforms, and potentially between 
the strike platforms themselves, and (6) lack of necessary available bandwidth to support 
robust rapid data transmission in support of RTR. This equates into a lack of real-time 
threat awareness on board the strike platform. 


Shortfalls two and six are addressed by this effort. Without requiring a change to the net 
protocols or integrity assurance, this effort is developing methods for extending the effective 
bandwidth of existing tactical networks. By utilizing algorithms and system structures which are 
typically not associated with throughput optimization, substantial improvements can be realized 
for extending the communications capabilities of existing networks. The technologies developed 
by this research will support the capabilities of Tomahawk Block [V+ or TSTAR. It will also 
apply to any digital network through optimization of available bandwidth. This effort is not a 


cure-all for network bottlenecks, but rather a best use of what is available. 


D. SCIENCE AND TECHNOLOGY SHORTFALL 


Link 16 is predominately a passive system. This means that messages, such as track 
updates, are transmitted so frequently that they need not be acknowledged by receiving 
platforms. Therefore, if a platform misses a message, it need only wait a few seconds for an 
update. The goal of the design within the surveillance NPG is to provide a complete tactical 
picture in twelve seconds or less, for as many as two thousand tracks. Although the total load on 
the link by the surveillance NPG is not as great as that produced by voice communications or 
video conferencing, it is significant nevertheless. 

In order to adapt the link to RTR requirements, both transmitting and receiving platforms 
need to be smarter, reducing both the level of redundancy in the messages and the frequency 
with which they are transmitted. The idea is to insert processor capability between the C2P and 
the JTIDS terminal on all platforms to distribute network control and manage message content in 
a smarter way.' Because of the complexity of the rules of the network and the communications 
between C2P and JTIDS, an agent based architecture is the ideal candidate: it is designed to 
operate transparently, can take action on its own volition, 1s extensible and flexible, and is 
capable of being included, and / or integrated, in future system upgrades, and will handle the 
complexity of network entry / passive synchronization, while maintaining maximized throughput 
capability of only “changed” information. Distributed control architectures in an object-oriented 
environment can produce smart and complex behaviors that are not generally achievable with 


traditional techniques. 


' The eventual target for this work is probably the CDLMS effort (Common Data Link Management System), 
which will at some point produce a system replacing the current C2P. 


E. TECHNICAL APPROACH 


1. General Discussion 


Depending upon available resources, the approach to the FY96 tasks was to establish 
performance objectives and baselines. Sanitized data from actual network operations were 
acquired from the Systems Integration Facility (SIF). This data established baseline for 
evaluating redundancies in network communications. From this data, a decrease in loading is 
expected to result from the technique(s) being developed by this effort. Additional candidate 
techniques are under development and will be tested separately. 

The software written to date has employed reusable, object-oriented methods/techniques. 
A need for a real-time object-oriented data base management system (OODBMS) is anticipated 
as system capabilities are developed. The system architecture is designed to incorporate such 
tools as they are needed and can be exploited. Also, a PMW 159 sponsored effort called the 
Common Data Link Management System (CDLMS), will result in an object-oriented tactical 
communication system. Thus, employing an object oriented style will reduce costs for future 
integration efforts. 

A number of commercial OODBMS’s, such as ObjectStore, Versant, ONTOS, and 
Polyhedra, are under consideration and are to be evaluated as the need arises. Their ability to 
satisfy real-time demands of link messaging, is considered a critical feature. The ability to 
manage storage and retrieval of temporal data, is also a critical factor. 

Finally, objects are by definition, independently executing processes that are designed for 
maintainability and reuse. From their hierarchical orientation, the levels of abstraction in object 
oriented systems are more explicit and straightforward than traditional styles. As the initial 
exploratory efforts are performed, and lower level object methods are created, developing more 


abstract levels of processing is relatively fast, reliable, and adaptable toward new capabilities. 


FE. ASSUMPTIONS 


The following assumptions are made with respect to the proposed modifications 
suggested herein: 

eAny modifications made between two C2P / JTIDS terminal linkages can be 
accomplished, as long as the rules for the particular network in question are followed. 

«Messages will have specific data elements recognizable to the C2P. As for transmission 
methods are concerned, data is data, and can be manipulated as desired, so long as the 
reconstituted message elements follow the assumption above and do not violate any link 
integrity requirements. 

«Link rules enforce standards. As long as the -end results obey link rules, the proposed 
modifications can be performed, given timeliness and robustness are maintained. 

*Rules evolve as systems evolve, tactics change, and lessons are learned. Software 


designed under this effort is flexible, allowing changes in rules without forcing system redesign. 


AGENTS FOR TRANSPARENT OPTIMIZATION OF 
-INFORMATION TRANSMISSION 


An “agent” is a relatively-independent software entity, or collection of such entities, that 
performs tasks on behalf of human users but also can perform on behalf of other computer 
applications or systems. There are two important features of software agents. First, they are 
anthropomorphic processes. As much as possible, agents behave and communicate in ways that 
are similar to and compatible with human behavior and communication. As such, they are not 
necessarily “smart” or “intelligent,” but like humans, they tend to be goal driven. 

Resource management is a common task for software agents. In this capacity, they 
operate at a higher level of abstraction than the user or system they oversee. Often they are 
separate processes initiated prior to the initiation of the system they oversee. Like human 
managers, they are able to “watch” user or system operations, detect problems, formulate 
corrective plans, and carry them out. Some can study the effects of their interventions and 


modify their behavior accordingly. 


Distributed set of intelligent agents may provide the means and method for overseeing 
the operations of an operational network such as Link-16. Present at each platform, observing 
transmissions, received messages, and user interactions, agents can be designed to optimize link 
performance and enhance operator efficiency. 

In late 1996, a demonstration capability was developed and an initial evaluation of 
network messages was performed. In 1997, an initial design of a software agent, hereinafter 
called “Agent,” was prototyped (proof of concept), while longer-range architectural ideas are 
considered. In the out years, the final agent architecture will: 

«Accommodate the differing needs of different platforms without recoding; 

¢Understand the rules of the links so that all its actions will conform to them; 

¢Be extensible, either directly or through cloning with different knowledge bases, 

to other messages and functions; 

When a message is sent from the C2P to the JTIDS, the agent determines, by checking its 
type, whether or not it is of interest. If it is not, the message is simply reasserted on the outgoing 
bus. 

The design goal for Agent architectures is to be able to accommodate future functional 
requirements by adding additional knowledge, leaving the engines and interpreters largely intact. 
The result is a system that can be extended at minimal cost. 

The key design issue is real-time performance. In general, the higher the level of 
abstraction, the higher the overhead. Therefore, particular implementations, such as Link 16, are 
driven by the time constraints of the links, available system resources, and scalability of the 
agent-based architecture. Fortunately, agent-based architectures for Intelligent Real-Time 
Systems and Real-Time Expert Systems, have addressed similar hard real-time constraints. This 


work draws upon those results. 


H. LINK 16 GENERAL DESCRIPTION 


l. Link-16 Functional Description 


Link-16, or TADIL J, uses the Joint Tactical Information Distribution System. JTIDS 
refers to the communication component of Link-16 that encompasses the software, hardware, RF 
equipment and the waveform that they generate. Among NATO subscribers, the equivalent term 
for JTIDS is the Multifunctional Information Distribution System (MIDS). Link-16 employs 
netted communication techniques and a standard message format for exchanging digital 
information among airborne, land-based and shipboard tactical data systems. Link-16 does not 
significantly change the basic concepts of tactical data link information exchange supported for 
many years by Link-11 and Link-4A. Link-16 provides technical and operational improvements 
to existing tactical data link capabilities. The improvements include nodelessness; electronic 
countermeasure (ECM) resistance; flexibility of communication operations; separate 
transmission and data security; increased number of participants; increased data capacity; 
network navigation features; and secure voice. Link-16 also uses a Time Division Multiple 


Access (TDMA) architecture, which provides multiple and simultaneous communication nets. 


th Link-16 Operation 


Link-16 operates at L-band frequencies (969 - 1206 MHz) with 3 MHz channel spacing 
and a power output of 200 - 1260. It transmits a frequency-hopping transmission pattern using 
51 frequencies at 3 MHz intervals, excluding identification friend or foe (IFF) sub-bands. 
Frequency-hopping and other spread-spectrum techniques make Link-16 resistant to jamming 
and data encryption makes it secure. The Link-16 message standard consists of one or more 70- 
bit words plus, error detection, correction bits, and symbols. The word formats are used to allow 


a single message to convey position, track data, weapons control and command messages. 


ai Link-16 Configuration 


The major components of the Navy shipboard Link-16 system include the following: 
Tactical Data System (TDS), Command and Control Processor (C2P), JTIDS terminal and 
JTIDS antennas. The TDS and C2P provide the tactical data to be exchanged. The JTIDS 
terminal and antennas provide the secure, anti-jam, increased capacity waveform. The JTIDS 
terminal is composed of two major components: the receiver/transmitter (R/T) and the data 
processor group (DPG). The R/T is common to all platforms. The DPG contains a digital data 
processor and an interface unit (IU). The IU is tailored specifically to each type of platform. 

There are two configurations of Link-16, known as Model 4 and Model 5. The Model 4 
implementation of Link-16-also referred to as Block 0 on Advanced Combat Direction System 
(ACDS) platforms-was designed as a transparent equipment upgrade to existing ship’s tactical 
systems. Model 5-also referred to as Block 1 on ACDS platforms-is the full and complete 
implementation of Link-16 in accordance with OS5161. 
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[. AGENT-BASED TECHNIQUES FOR REAL-TIME SYSTEMS 


1. Introduction 


The following summary 1s from Huang [63]: 


George Saradis introduces a three-level hierarchy [Saradis, 1985]. Acar and Ozguner 
present an alternative architecture that organizes the system into a multiresolution 
hierarchy by identifying its components and examining the physical relationships among 
them [Acer and Ozguner, 1990]. Antsaklis and Passino describe a hierarchical control 
architecture that uses a hybrid approach to model systems with a high degree of 
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autonomy [Antsaklis and Passino, 1993]. Successive delegation of duties from higher to 
lower levels is one of this hierarchy’s important characteristics. In another chapter of 
Antsaklis and Passino, Meystel describes a nested hierarchical control theory that 
includes the concept of treating design and control as a continuum [Meystel, 1993]. 


Regarding implementation of intelligent control systems, research has focused on 
software technologies and computer-aided software-engineering environments. Sweet 
and his colleages identify key software technologies for the Aerospace Industries 
Association [Sweet et al, 1989]. Simmons describes a Task Control Architecture 
[Simmons 1990]. One limitation of TCA might be scalability because it is not intended 
to model multiple-cooperating agents. Object-oriented paradigms are becoming popular 
for handling the representation problems of software systems, but they are not suitable 
for all problems. For example, Schneider and his colleagues developed a flexible, object- 
oriented, real-time software implementation tool called ControlShell [Schneider et al., 
1994]. But this tool does not address the issue of architecture; perhaps a reference-model 
architecture could complement its capabilities. 


Huang is at the National Institute of Standards and Technology (NIST) where, for over 
two decades, Jim Albus has been developing the Real-Time Control System (RCS) reference- 
model architecture. A reference-model does not describe how system structures are represented 
and implemented, but rather seek to conceptualize the high level functionality and process 
interdependency. Object-oriented (OO) paradigms have become popular because they can 
reflect the inherent structure of reference models. Given a reference model or system 
architecture, the actual implementation, as driven by the model or architecture, is typically a 
separate design effort. Intelligent real-time system architectures are discussed in more detail in 


the next section. 


ep Intelligent Real-Time Systems (Robotics) 


An approach and methodology for engineering intelligent real-time systems is discussed 
by Durham [44, 45, 46]. In terms of systems architectures, Durham considers intelligent real- 
time systems functionally equivalent to intelligent robot systems. The two types of systems share 
similar requirements and objectives, and only differ in terms of the “plant” or environment for 
which they interact. When a robotic agent interacts with a subset of a system such that its “plant” 
is restricted to system software, such agents have been called “softbots,” i.e. software robots. 


Softbot applications do not typically have hard real-time requirements and the real-time 
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limitations of softbots is an open issue. To address such issues, this effort capitalizes on the 
recent advances in autonomous systems and telerobotics. 

Figure 4, below is a diagram of a generic intelligent system architecture derived from 
some early results in the ARPA Autonomous Land Vehicle (ALV) program. Figure 5 is from 
Meystel’s recent work in “Semiotic” system architectures [59]. These diagrams illustrate the 


generic high level architecture of real-time intelligent systems. 
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Figure 5 
Figures 6 and 7 are two diagrams from an intelligent system architecture as described by 


Valavanis and Saridis [60]. These diagrams further illustrate a functional organization and 
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layering. The highest level processes are similar to the executive level within a business 
organization. Longer term organizational structures, such as strategies and mission statements, 
are the types of objects and data structures to be processed. The coordination of day-to-day 
operations is a lower level management function. Specification and design of specific tasks 1s a 
critical “coordinator” function. Finally, the labor of humans and machines actually execute the 
operations of the organizational entity. A “topology” of organizational structure has emerged 


from previous efforts in real-time intelligent systems. 
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These diagrams illustrate an anthropomorphic model for intelligent real-time systems 
design. This type of system architecture exhibits a number of properties. First, a hierarchy of 
processes is defined. The “higher level” processes require more “abstract” processing such as 
symbol creation and manipulation. “Lower level” processes directly interact with the 
environment. For Agents, the environment is the message data stream. Secondly, timing 
requirements tend to be inversely proportional to the level of a process. Low level processes 
need to be highly responsive. High level processes are often very slow to respond. This layering 
of timing requirements allows a system to maintain sufficient interaction with its environment 
while working to improve its capabilities. The “scope” of systems processes tends to be layered 
in a similar manner. Higher level processes incorporate system-wide and long range data 
elements, i.e. they process the “big” picture. Low level processes have well defined and narrow 
tasks tailored to specific increments of time. This leads to a third characteristic of intelligent 
real-time systems. They are structured such that an “abstract” “high level” goal or set of goals 
can be designed and understood without explicit attention to the numerous run-time or 
operational details. The system is designed to map the high level goals into a set of lower levels 
functions necessary to achieve the given goal(s). Lower level processes, such as control loops, 
have their own low level goals, such as set points. The specific low level processes performed at 
specific points in time are determined by, or at least influenced by, higher level processes. 

Figure 8 1s also from Valavanis and Saridis [60]. This diagram illustrates that intelligent 
control is the intersection of three separate areas of work. The requirements and objectives of 
Intelligent Control inherently overlap with Artificial Intelligence, Operations Research, and 
Control Theory. Each one of these disciplines in turn interact with each other and define a 
number of specialized subdisciplines. From this organizational perspective, a systems designer 
can recognize that, if properly managed, a considerable amount of knowledge and talent can be 
utilized for a real-time system application such as throughput optimization of communications 
networks. The development and demonstration of this technology insertion capability is central 
to the Agent concept. A mechanism for efficiently and effectively inserting new capabilities into 


operational legacy systems is a primary objective and focal concern. 
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3. Real-Time Expert Systems 


Expert systems are not typically real-time systems in terms of their inherent architecture. 
The heuristic search algorithms typically employed are not guaranteed to meet hard real-time 
requirements. A number of intelligent control systems employ “Expert System” algorithms and 
perform within their requirements. Expert systems have become an integral component of 
intelligent systems, but their application tends to be best for “organizational” processes. Fuzzy 
logic expert system techniques have been recently demonstrated and they may prove to be quite 


valuable at the coordination and execution level of the Agent processes [61]. 
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J. OTHER CRITICAL TECHNOLOGIES 


IE Information Theory: Mathematics of Communication 
a. Definition of Information 


The following is from Hamming [49]; 


Suppose that we have the source alphabet of g symbols s,, s2, ... , s,, each with its 
probability p(s,) = p,, p(S2) = p2, ... , p(S,) = Pg. When we receive one of these symbols, 
how much information do we get ? For example, if p, = 1 (and, of course, all the other p; 
= 0), then there is no “surprise,” no information, since you know what the message must 
be. On the other hand, if the probabilities are all very different, then when a symbol with 
low probability arrives, you feel more surprised, get more information, than when a 
symbol with a higher probability arrives. Thus information is somewhat inversely related 
to the probability of occurrence. 


From an information theoretic perspective, “surprise” is associated with the probability 
of a communication event. Data can be transmitted but unless there is a lack of predictability, 
there is no surprise and therefore no information content. Agent based communication links 
capitalize on this understanding of information content. There are a number of ways that the 
degree of “surprise” can be taken out of network messages. Traditional data compression 
techniques capitalize on a relatively small number of possible approaches. Traditional data 
compression, and coding theory in general, will be exploited and incorporated within the Agent 
architecture, but this is not the technology being developed. 

Agent based communications should not be confused with data compression 
technologies. Through efficient management and accounting of what 1s known, or can be known 
before messages are transmitted, agent based communication links share the knowledge in a 
manner such that there is less “surprise” in the messages transmitted. Thus, Agents are able to 
communicate such messages with fewer bits. 

By incorporating engineering and design knowledge of the platform tracks, the behavior 
of the tracks becomes predictable and, thus, less of a surprise from one message to the next. 


Agent based communication also provides a mechanism for incorporating command and control 
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(C2) knowledge. For C2, different track types typically have different operational requirements 
for position resolution and update rate resolution, the operational requirements for actual 
message transmission times and resolutions can be known before messages are transmitted, and 
therefore, the track messages can be communicated at a lower rate with fewer bits per message. 
Also note that redundancy can be added when operationally required for increasing the 
confidence that messages will be received. 

Agents are network processes that have a primary goal of identifying and sharing system 
knowledge that is not shared by the current communication links. One of the assumptions, as 
stated earlier, is that with minimal impact, such a collection of processes can be inserted into an 
existing communication network. With Agents, otherwise unutilized knowledge is then used to 
take the “surprise” out of the messages as they were originally communicated. Agents exploit 
knowledge within the scope and bounds of typical data compression methods, but data 
compression is not the technology under development. Data compression related knowledge is 
considered a relatively small portion of the system wide tactical knowledge available for 
maximizing information throughput. By identifying and accounting for system wide knowledge, 
more robust and effective communication 1s realized while increasing the effective throughput of 
the tactical network. Agents, by design, are background network processes which continuously 
work to identify and manage tactical network knowledge for achieving their own goal of 


maximizing effective throughput. 


b. Measures of Information, e.g. Entropy 
Claude Shannon's paper in the 40’s established a mathematical basis for the theory of 


communication [56]. Shannon defined a mathematical function, called entropy, for measuring 


information content. Shannon's entropy function is defined as 


Z2 


where N is the number of symbols communicated, q is the number of possible symbols, and _p, is 
the probability that the 7— th symbol is in the N length message. As noted in Hamming [49], "It 
is important to realize that a remark like 'Consider the entropy of the source’ can have no 
meaning unless a model of the source is included. Your estimate of the entropy of a source of 
symbols therefore depends on the model you adopt of the structure of the symbols.” 

A variety of metrics exist for defining and determining information content. Kapur [51, 
52] provides a number of examples and references. There is no single absolute measure of 
information. Entropy and working model of the source is necessary. A model is needed to 
specify the symbol] set and probabilities for the given symbols for all points in time. Usually, the 
probability distributions are assumed to be “stationary.” This means that the statistics of the 
symbols do not change with time. Operationally, nonstationary data is quite common. Thus, 
potential performance of “optimal” data compression schemes such as Huffman coding, cannot 
be realized. Alternative schemes, such as Lempel-Ziv dynamic dictionary based approaches, 
often demonstrate better operational performance. Thus, there is no one ideal technique or 
underlying model for a given coding scheme. 

Ideally, a more abstract “context dependent” network process would dynamically identify 
and select the appropriate measures of information and their most appropriate models. Such 
metrics and models can then be selected based on the degree of compression which can be 
operationally realized at a given point in time. While managing and exploiting other types of 
knowledge, such as “system design knowledge” and “C2 knowledge,” Agent processes can also 
manage “data compression knowledge.” Thus, improved operational performance of traditional 


data compression schemes is inherent in the Agent architecture. 


Cc. Universal Compression and Retrieval 


The following summary note is from Krichevsky [50]: 


The output of a source may be compressed up to its entropy, not more. It is the main fact 
of the source coding theory, which has its origin in Shannon (1948). The first theoretical 
compressing code is Shannon’s. It happened to be very close to Morse’s, which was 
developed empirically a century earlier. Shannon’s code is very simple, although not 
optimal. An optimal code for a stochastic source was constructed by Huffman (1952). It 
may be used to compress an individual word. The frequencies play the role of 
probabilities. The encoding may be either two-pass or one-pass. In the first case the 
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frequencies of letters are counted beforehand, then a code is built. In the second case the 
code is changed along with the word reading. 


Output words of Shannon or Huffman’s codes are of different lengths. There is a 
compressing code, whose output words are of equal length. It was developed by first G. 
L. Khodak (1969) and then by F. Jelinek and F. Schneider (1972). 


A decipherable code for integers is constructed by V. Levenstein (1968) and P. Elias 
(1975). 


Hansel (1962) and Krichevski (1963) exploited the source coding to lower-bound the 
length of threshold formulas. 


The Kolmogorov complexity bridges the theory of algorithms and the information 
theory. Any code, including Lempel-Ziv’s, move to front, etc., is only a majorant of 
Kolmogorov’s. 


In other words, majorants of Kolmogorov codes provide a theoretical framework for 
compression algorithms. In this context, optimality 1s tied to computability, as well as, 
compressibility. Computing cost 1s typically a critical operational parameter, but until recently, it 
has not been an integral theoretical component. 

Krichevsky also notes that “for many years the target of the source coding theory was the 
estimation of the maximal degree of the data compression. This target is practically hit today. 
The sought degree is now known for most of the sources. We believe that the next target must be 
the estimation of the price of approaching that degree. So, we are concerned with the trade-off 
between complexity and quality of coding.” The reader may need to be reminded that in this 
theoretical context, the sources are assumed to be known and well behaved. 

Computing time is a critical factor for agent based communication links but until recently 
it has not been a theoretical focus of concern. Accurate and robust source models are another 
critical operational concern that is often overlooked by information theorists. Krichevsky’s 
analysis assumes that the sources are known and well behaved. Temporal variability is not 
within the context of his work. 

Within its own scope and context, coding theory provides a basis for determining 
compressability. With full knowledge of their utility and limits, compression algorithms can be 
identified and utilized at the most appropriate times. As the characteristics of data sources 


change with different tactical situations, software agents can activate the most appropriate 
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compression algorithms and source models for the particular context. Agent’s can operate on 
knowledge within and beyond the scope of coding theory and data compression. How these 
bodies of knowledge are coordinated is of particular concern for optimizing the operational 


throughput of a network. 


d. Universal Prediction, e.g. Machine Learning, Generalized Approximation, etc. 


Universal prediction is another recent focus in coding theory. If a source is well behaved 
and can be modeled, then the source should become known over time and the sequence of 
symbols should be optimally predictable. Theoretically, if the symbols can be predicted, optimal 
coding schemes should incorporate such predictability. Traditionally, predictability is not 
assumed. For adaptive schemes, lack of predictability is the alternative focus. 

Universal predictive coding schemes are rooted in the same mathematics as related areas, 
such as machine learning, generalized approximation, pattern recognition, classification, and 
adaptive filter theory. Probability and mathematical statistics are typically developed and applied 
using the numerical methods of linear algebra. When possible, these techniques often combine 
empirical and analytical modeling methodologies. Analytical models are preferred over 
empirical “black box” approaches. 

Just as the Krichevsky and others are interested in bridging complexity theory and coding 
theory, those working in the area of universal prediction and interested in bridging the 
mathematics of prediction and coding theory. The Agent approach under development is not 
limited to coding theory, or those areas of coding theory most related to efficient network 
communications. As previously noted, coding theory has its limitations and Agents address those 
limitations while exploiting opportunities which are not within the scope of traditional coding 
theory approaches. 

Coding, complexity, and prediction can each be exploited by a more abstract system 
process. At this level of abstraction, a spectrum of competing data compression algorithms can 
be evaluated. This can be done alongside competing prediction algorithms. For real time 
execution, algorithmic complexity is a critical factor for both coding and prediction. The Agent 
architecture is designed to manage these traditional components, but these plug-in capabilities 


could probably be managed by a number of other more traditional techniques. The ability to 
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identify and quickly utilize system wide knowledge, is the focus of agent based communication 
links, i.e. Agents. The agent based architecture provides the mechanism for incorporating 
additional bodies of knowledge for maximizing network throughput. 

Figure 11 illustrates the relationship between pattern recognition and data compression. 
In both cases, invariances are of special interest. The goal is to identify functions whereby 
predictable and recognizable patterns can be identified and exploited. A number of “plug-in” 
pattern recognition capabilities have recently become available. Agents are being designed such 
that those capabilities can be managed and exploited. The design objective is to demonstrate 
“coordination” and “organizational” network processes that manage C2, system design, data 
compression, pattern recognition, and other bodies of knowledge for the purpose of maximizing 


the effective throughput of tactical communication networks currently operating in the Fleet. 
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As mentioned earlier, universal predictive coding is inherently related to machine 
learning. Intelligent real-time systems share a similar interest in machine learning. The objective 
for hierarchical intelligent systems is to design systems such that they can learn to create optimal 
tasks and coordinate their execution. The following is from Lima and Saridis [62] and discusses 


work related to this objective: 


A robot can learn from the data provided by its external sensors (such as cameras, ultra- 
sound transducers, or proximity detectors) or internal alarms (such as a battery failure or 
a time-out while a process runs). Often the goal is to learn how to recognize a scene or an 
object in the scene, by either a statistical or a structural approach. The robot explores the 
similarities of the scene or object with previously stored patterns. Some learning 
programs record the strategy used to solve a particular problem so that they don’t have to 
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search for a solution when the problem emerges again [Samuel 1963]. Other programs, 
such as those based on neural networks, begin with a random network and continually 
change the connections (or weights) among network nodes, to reflect a bad or good 
performance as they try to accomplish their job [Hertz 1991]. This later type of learning 
algorithm is usually classified as unsupervised if it receives no information about the 
correctness of its output, and as supervised if the goal is available. We can improve the 
algorithm’s performance by measuring the error between its goal and its actual output. A 
third category is reinforcement learning, where limited information is available about the 
algorithm’s instantaneous performance, typically in the form of success or failure signals. 


Since the late sixties, various strategies based on reinforcement learning have emerged to 
address the control of complex systems. Reinforcement learning is particularly 
interesting for robotics, where it involves the exchange of small bandwidth information 
(failure or success) between robotic subsystems. In typical applications, such as 
unmanned space or underwater missions, the cost of large bandwidth for 
communications between the central command (earth controller or main-vessel 
controller) and the vehicle 1s prohibitive. Designers ‘can reduce this cost by increasing the 
autonomy of the machine involved in the mission. 


Fu was perhaps the first to write about learning control systems and to define intelligent 
control systems as systems of an interdisciplinary nature where artificial intelligence and 
automatic control intersect [Fu 1986]. Moreover, he introduced the concepts of stochastic 
automata and stochastic grammars. Narendra and his associates have also developed 
work on stochastic automata [Narendra and Thathachar 1989]. In the last few years, 
Sutton and his associates have explored reinforcement learning solutions that associate 
these two views of stochastic automata [Sutton 1988]. 


A frequent limitation of reinforcement learning applications to robot problem’s is the 
problem’s large state space. Lin attempted to tackle this problem by providing initial 
knowledge to the robot and by endowing it with generalization capabilities via neural 
nets [Lin 1994]. Sutton described an algorithm that learns from both virtual experiences 
in an internal-world model and real-world experiences, to accelerate the learning process 
[Sutton 1990]. Both of these authors used Watkins’s Q-learning algonthm, which 
includes a learning-performance function [Watkins and Dayan 1992]. 


Finally, Wang and Saridis used reinforcement learning to improve performance at the 
intermediate level of the hierarchy [Wang and Saridis 1993]. And Mclnroy and Saridis 
proposed reliability as a practical measure of primitive-task performance — but did not 
consider the computational cost [McInroy and Saridis 1994]. 


The above discussion illustrates that neural nets are but one technique of machine 


learning. In practice, neural nets are more accurately described as a family of regression 
techniques utilized to generate empirical models. When there is limited communication 
bandwidth between agent processes, e.g. mother ship and vehicle, agents can minimize 


communication requirements. For purposes of the Agent architecture, agents with synchronized 
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models only need to communicate when one of the agents recognize a deviation from the “real 
world,” i.e. part of its environment not shared with the other agent. Furthermore, since the goal 
is to minimize communication requirements between such agents, synchronized learning 


algorithms are another body of knowledge to be exploited. 
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transcontinental phone conversations were plagued with annoying delays due to the limitations 
of hardwired signal transmission. The addition of any process in the path of C2 messages is an 
even greater concern. Because Agents map messages and communications to more efficient 


representations and transmission timing, they inherently introduce delays on a per transmission 
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CODESIGN: SOFTWARE ENGINEERING FOR REAL-TIME SYSTEMS 


Delays in communication are a primary concern for tactical networks; just as 
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Presentation | 












basis. If Agent processes are introduces at the 1553B bus, very small latencies may be required. 
This may be a significant constraint. If the Agent processes are designed into the CDLMS, much 
flexibility will be gained, but message management will still delay message communications. 
For any communications network, messages are typically delayed due to typical management 
functions. The critical concern is that such delays be minimal. For time critical data compression 
applications, data compression processors (DCP) are typically incorporated into the system 
hardware. This is a “plug-in capability” that our agent-based approach can manage in the course 
of minimizing message traffic while maximizing effective throughput. Other algorithm specific 
application processors (ASIP’s) are commercially available. Agent’s provide an opportunity to 
utilize those off-the-shelf plug-in capabilities, as well as. 

Several domains such as embedded, real-time, and reactive systems are the application 
areas for which hardware / software codesign techniques are most beneficial. They are beneficial 
because the increasing complexity of advanced systems combined with technological 
advancement requires new design methods and integrated tool environments. 

Hardware / Software codesign is different from conventional approaches in that it 
continuously relates the hardware development cycle to the software development cycle. Hence, 
hardware decisions significantly affect software design activities and vice versa. In codesign, the 
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entire problem is treated as a whole. The “co” means primarily together. However, it also 
expresses a design flow that is properly coordinated; a joint effort among designers from 
different areas. The effort is inherently concurrent in that the majority of all design steps are 
carried out in parallel by a team that guides, coaches, and supervises the design process. Ideally, 
several teams of experts develop system components rapidly and resolve problems in a timely 


manner. 
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SOFTWARE REQUIREMENTS - A FUNCTIONAL DISECTION LEADING TO A 
PROPOSED DESIGN FOR IMPLEMENTATION 


Agent will not be specific to any particular digital network, but will be 
appropriate for any digital network where it can intercept and alter messages to 


and from all nodes on the network. 
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Agent will be a software agent in structure. 
Agent will be able to run under any common operating system. 


Agent, in the engineering design, does not require any particular computer 
language or programming style. 


Design & Architecture must support modular concepts of engineering and be 
adaptable to future enhancement / expansion. 


The design of Agent should be as general as possible within the constraint of 
performing within the tactical network environment and Link-16. 


The software and design should be readily adaptable to major link component 
upgrades, as well as future systems and technologies. 


Agent control should be distributed rathér than centralized. 
The Agent must be instantiated on every node in the link. 


The Agent must not require a special or central node for control or any other 
purpose. 


The Agent can continue to operate correctly with the loss of a number of 
transmitters or receivers. 


Functions & Operation 


Agent will be able to perform all known heuristics (e.g., delta messaging, update 
bundling, extrapolated updates, and so forth), and be extensible to other 
analogous techniques as they are developed. 


Agent must decouple its processing components from its knowledge of link rules 
and operations, so that a simple substitution of link rules and operations can 
enable it to work with other tactical links (e.g., Link-11, Link-4A, Link-22). 


Instantiations of Agent will be able to communicate with each other in order to 
optimize their operations. 


Communications between instantiations of Agent should not be visible to host 
processing systems and the C2P (JTIDS, of course, will be aware of these 
transmissions). 


Inter-agent communication should not in itself constitute a significant burden to 
link operations (that is, should consume relatively little bandwidth or link 
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overhead). 


D. FUNCTIONAL REQUIREMENTS 


These requirements are specific to Link-16, but many may apply to other digital 
networks. 


1. Agent will increase the effective bandwidth of one or more Link—16 NPGs. 
a) Agent will be able to measure the message loading within an NPG. 


b) Agent will be able to detect when the message loading reaches, or is about to 
reach, saturation. 


c) Agent will be able to selectively employ an heuristic or combination of 
heuristics to reducing the loading within an NPG (and, by so doing, increasing 
the effective bandwidth). 


d) Agent will rely on Time Slot Reallocation (TSR) to distribute the additional 
effective bandwidth to other purposes, including RTR messages. 


2. No “rules of the link” will be violated by Agent operations. 


3. Agent operations will degrade operations within an NPG to the minimum extent 
necessary to prevent or delay NPG saturation. 


a) Agent will employ lossless techniques whenever possible. 
b) Agent will employ lossy techniques only when necessary to avoid saturation. 
c) Agent will explicitly manage NPG degradation due to its operations. 


d) Agent will employ lossy techniques only when such losses are operationally 
acceptable. 


4. Agent will accommodate all current and planned users of J-Series information. — 


5. Agent will not delay the transmission of J-Series messages beyond the point of 
military usefulness to the receivers within the tactical context. 


6. Agent will be able to function transparently on the bus that leads to or comes from 
the JTIDS terminal (when implemented in a JTIDS environment). 


7. Agent shall work when implemented on Link-16 but not be specific to Link-16. It 
should readily be reconfigurable to operate within other tactical links. 
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8. Agent will not fail or degrade if one or more nodes unexpectedly drop off the link. 
There will be no main or central node. 


9. Agent will be able to operate successfully in an environment with degraded 
connectivity (that is, one or more receivers fail to receive a complete message stream, 
probably due to loss of line of sight). 


10. Agent will be able to measure its own effectiveness and dynamically alter its 
operations in response to those measurements. 


11. Under no circumstances will Agent operations cause an erroneous J-Series message 
to be received at the host component. 


12. Agent will provide a complete tactical picture within militarily-acceptable intervals, 
which may be context sensitive. 


a) To platforms recently entering the link. 


b) To passive listeners. 
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Es KNOWLEDGE-BASED COMPONENTS 


iL General 


The knowledge-based components for Agent are especially designed for Agent 
operations. Many changes from the usual knowledge-based paradigms were necessitated by the 
need to do more than simply recognize situations, but also to perform actions in response to 
those situations. Therefore, this section is designed to describe the special properties of the 
knowledge-based components so that, during detailed design, appropriate tools can be properly 
designed (e.g., translators from KIF to Agent form, translators from Agent form to semantic 


networks, and the inference engine). 


ap Semantic Networks 


Facts are truth assertions used either to create or edit a semantic net, or provide the input 
to inferencing. They are also used by the metarule functions. It 1s assumed that the reader has a 
general knowledge of semantic networks, facts, production rules, inference engines, and other 


related terms used in artificial intelligence. 

a. The Semantic Network 

Underlying the facts and rules of Agent is the concept of the semantic network. This 
network is created within global memory available to any of the processes (and processors) of a 


single instance of Agent. The semantic network is created at agent initialization by the use of 


facts with an expanded grammar. For example, 


A message 1s_a null class 
The value facet of the max_delay slot of the message is 25 ms 


The first statement creates a object called “message” and assigns it with an “is_a” 


relationship to the null class or object (which is created automatically in shared memory). The 
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second statement creates a slot called ““max_delay” within the message object. A component of 


the initialization process creates this semantic network in persistent store (using IBM’s ABE 


terminology). 
In the present design, this network cannot be added to during agent operations. Although 


“is a” statements during initialization create classes, “is_a’” statements in rule consequents create 


instantiations (or objects). 
The inference engine “Jooks up” values in the semantic net when antecedents reference 


slots in the semantic network, and “sets” values in the semantic net when consequents fire. 


Null Class 
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Figure 19, Agent Semantic Network 


Agent-to-Agent 





b. Slots and Objects 


(1) NULL slots and the NULL object. 


A special object is always present at the top of the semantic network, the null frame (or null 


class or null object). All classes and instantiations are subclasses of the null frame. It has many 
uses. 


It is awkward to always have to explicitly refer to a slot reference in the rules: 
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The <slot name> of the <object name> is <value> 
To simplify where possible, the <object name> always defaults to the null object. For 


example, 
The rules below use this construction often: 


IF Agent is operating 


This usage refers to the “Agent” slot of the null object, whose value might be 
“operating.” On the other hand, “The mode of Agent is operating” refers to the mode slot of the 
Agent object. 


(2) Slot References 


A slot reference is of the following formats: 


<frame> 

<slot> {<frame>] 

<slot> [of ANY <frame>] 
<slot> [in ANY <frame>] 
[THAT] <frame> 
[THOSE] <frame> 


If the name of the slot 1s omitted, then the default slot of the named frame is referenced. 


If the name of the frame is omitted, then the null object is assumed. So the following are slot 


references: 
1. The door 
Qe The door of the house 
3. The door of ANY house 
4. THAT | THOSE door 


In the first case, since the name is omitted, the slot is part of the null object. In the second 
reference, the slot is part of the house frame. If both are used they reference different values. In 
the third form, the slot reference is to the set of all slots of all instantiated houses. In the last 
form, which 1s always paired with one or more ANY constructions, the reference is to all slots 
referred to by the matching ANY constructions. 

(3) | Dynamic object and slot creation 

Note that these constructions do not create slots or objects 1n antecedents, but do create 

slots and objects in consequents. If there has been no statement such as 


THEN Agent is operating 


gy 


there is no “Agent” slot in the null object when 


IF Agent is operating 
is encountered by the inference engine. Therefore the test fails and the slot is not created. 


(However, the slot could have been predefined and initialized during Agent initialization—the 
point is that it doesn’t have to be.) This kind of dynamic object and slot creation makes it much 
easier to write rules where perishable knowledge is involved, and, in fact, 1s the preferred way of 


writing such a rule. 


F. FACTS 


1. General Forms 


Facts in Agent are references to a semantic network. Facts consists of the following 
forms: 


<slot > [of <frame>] <declarative operation> <value> 
<slot > [of <frame>] <relationship> <frame reference> 
[<facet >]of <slot > [<frame>] <declarative operation> <value> 
The <frame> refers to the class or object itself, the <slot > is the name of a slot within 


that frame. The <facet> refers to a facet within a slot. Items within square brackets are 
optional—when omitted, the reference defaults to the null object. Facet references are only used 
in building the semantic network, which takes place at Agent initialization time. 
Sample declarative operation: 
1s 
Sample relationships: 
is a 


has a 


Below are a set of sample facts, with their forms in parentheses: 


The default_facet of the weight slot of the airplane frame is 32,000 lbs (3) 
The house is green (1) 
A house is_a building (2) 
A building has _a door (2) 
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Note that there are a number of words used for readability that are completely ignored by 
Agent, such as “the” and “a.” 

In a later section of this report, the use of facts in rules is explained and differences in 
syntax and semantics are noted. This section does not explain how the various forms of facts are 
used. It is often helpful to have plural forms of slot or frame names. When defining a semantic 
net, for example, the following form can be used: 

The house(s) 1s_a building(s) 
This creates a house frame with a synonym for house being houses. There is no meaning 


associated with plural forms—they are used precisely as singular forms. 


2. FactSets 


FactSets are collections of facts referenced by name. See under MetaLanguage. 


G. PRODUCTION RULES 


L. General Forms—Antecedents and Consequents 


The general forms of Agent production rules are as follows: 


1. <slot reference> <operation> (<value> [<units>} ) [ONLY | ALSO] 
Zz <slot reference> <comparison> <value [<units>] ) [ONLY | ALSO] 
oe <slot reference> <comparison> <slot reference> [ONLY | ALSO] 
4. <directive> <slot reference> | <frame reference> 


2. Comparisons 


The following comparisons are defined in Agent: 


is - a positive statement of truth 
isn’t - a negative statement of truth 
is_greater_than - > 

is greater than_or equal to - >= 
is_less_than - < 
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is less than_or_equal_to - <= 

is equal to - numeric equality 

is not - logical negatation 

is identical_to - non-numeric equivalence 

is the_same_as - non-numeric equivalence, less forceful than equality 

is _different_from - non-numeric non-equivalence, less forceful than is_not 


These all have meanings which are applied on a concete, and abstract formulation of 


comparisons. 


2 Antecedent format 


An antecedent appears in the following format: 
1. <slot reference> <comparison> <value> | <slot reference> 
2. There is <object > 
The following are examples of antecedents of the first form: 
IF The color of the house is green 
The color of the house is_the same_as the color of the barn 
The mode is delta_messaging 
THAT message 1s_a J3.2 
These antecedents, when referenced, find the appropriate slot reference, perform the 
comparison, and return a truth value. It is important to note that they change nothing. In the last 
antecedent shown above, the “is a” checks to see if any message signified by the THAT 
construction is instantiated as a J3.2 message (or instantiated from one ‘of its subclasses). An 
object can have an “is_a” relationship to any number of classes. 
Each antecedent is implicitly connected by logical conjunction. However, an OR 
construction can be used when parentheses are added: 
IF (The color of the house is green OR 


The color of the house is red) 
The color of the house is the _same_as the color of the barn 
The mode is delta_messaging 

This form, when compiled, results in two separate rules with no OR construction. 


Antecedents of the second form are special. The parser, upon seeing “There is” beginning 


an antecedent, checks to see if there have been any instantiations of the object references, and 
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returns TRUE if there have been, FALSE otherwise. In addition, there is an implicit ANY 


involved, in that subsequent uses of THAT will refer to the instantiated objects. 


4. Consequents 


<slot reference> <operation> <slot reference> | (<value> [<units>]) 
The operations in consequents change the values of slots or create new relationships. The 


defined operations are as follows: 
1S 
ISs_a 


has a 


Consequents are executed in the order given. 


5. Sample Complete Rule 


IF (The color of the house is green OR 

The color of the house is red) 

The color of the house is_the_same_as the color of the barn 
THEN The house is desirable 

The price of the house is unknown ONLY 


This rule is provided to illustrate many of the bad things one can write in rules. For 
example, no specific house is referred to. Therefore they will fail since the do not refer to 


instantiations. The rule should have been written as follows: 


IF There is a house 

There is a barn 

(The color of THAT house is green OR 

The color of THAT house is red) 

The color of THAT house is_the_same_as the color of the barn 
THEN The house is desirable 

The price of the house is unknown ONLY 


In this version of the rule, the consequents are vague. Since, in the first consequent, we 
refer not to “THAT house” but, simply, “house,” the value “desirable” is concatenated (see 


below) with other values in the default slot of the house frame, if there is one. Since this is a 
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modification to declarative knowledge, all houses would default to “desirable” as a result. 
Similarly in the second consequent. Here’s another try: 


IF There is a house 
There 1s a barn 
(The color of THAT house is green OR 
The color of THAT house is red) 
The color of THAT house is_the_same_as the color of barn 
THEN The appeal of THAT house 1s desirable 
The price of THAT house 1s interesting ONLY 
Note that the first two antecedents identify the set of instantiated houses and instantiated 
barns. But the “color of the barn” reference will probably cause a problem since what we are 
probably interested in is the set of houses that have barns of the same color. So, finally, here is 
the form that seems correct: 


IF There is a house 
THAT house has_a barn 
(The color of THAT house 1s green OR 
The color of THAT house 1s red) 
The color of the barn of THAT house is_the_same_as the color of 
THAT house’ 
THEN The appeal of THAT house is desirable 
The price of THAT house is interesting ONLY 


Note that “has_a” relationships amount to a special type of slot reference (special in that 


all of the slots and other linkages of the barn frame are now part of the house frame). 


H. CONCATENATION IN THE RULES 


Multiple values can be assigned to the same slot simultaneously. 


THEN The house is green 
does not refer to any house in particular (it isn’t “THAT house is green”) and there is no 


object reference. Therefore a slot is created in the null object called “house” and its value is 
assigned to be “green”. (Slots are automatically created when referenced—they do not all have 
to be predefined in the semantic net creation step of agent initialization. They are never 


removed. ) 


j ae : 
~ Two uses of THAT in the same antecedent cause a pair-wise comparison. 
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THEN The house is green 
The house is big 


The above concatenates two values in the house slot of the null object, “green” and “big.” 


Therefore, 
IF The house is green 
succeeds, because “green” is one of the slot values. 
IF Xx 
THEN The track of that message is xxxxx 


The track of that message is yyyyy 


In this construction, the message referred to as “that” message now carries both track 
IDs. This is because the slots of the object? concatenate values assigned to them rather than 
replacing them by default. A query as to the track ID will match as long as one of the 
concatenated values match. 

If it is desired that only one value be present in a slot, there is a directive for that in the 
production grammar: ONLY. It looks like this: 

IF xX 
THEN The track of that message is xxxxx 
The track of that message is yyyyy ONLY 

Of course, the assignment of xxxxx wouldn’t actually be in the real rule if ONLY was 
meant. When a consequent ends in ONLY then all concatenations are removed and the single 
value is assigned to the slot. 

The temporary message is where all operating processes/processors assemble a batched 
message. There needs to be only one of these, as each process/processor will contribute to a 
single output message. They only need to lock that message while they add to it. Also, if the 
message is long enough, or the oldest update has aged enough, the message becomes an output 
message and is deinstantiated as a temporary message. Any process with the authority of adding 
to the temporary message can make this switch. Also, this is how the exception handler outputs a 


message when it senses and exception condition. 


* An “object” can either be a class (frame) or an instantiation of a class (frame) in this document. 
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ANY/THAT/THOSE CONSTRUCTIONS 


l. General 


When ANY appears in an antecedent, the inference engine creates a list of all objects that 


satisfy the specified conditions (if any). Thus, 


IF The status of ANY message 1s late 
will create a list of the internal identifiers of all late messages. The THAT (or THOSE) 


construction then refers to all items in that list. Therefore, 
IF The status of ANY message 1s late 
THEN The status of THAT message is output 
changes the status of every instantiation of message with “late” status to “output” status. 


If there are no objects (instantiations), then ANY fails. 


ee Subsets 
IF The status of ANY message is late 
The type of ANY of THOSE message is video 
The time of ANY of THOSE message is today 
RULE THOSE messages are no good 


In this instance, the THOSE in the consequent refers only to “late video messages 
generated today.” In this construction, the antecedents have order (each subsequent ANY creates 
a subset of the previous ANY). However, in the consequent, only the smallest subset is referred 
to. This is the only instance in the grammar where the antecedents must be ordered. Therefore it 


may take several rules to inference properly. 
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iS; Evaluation Order 


A slot has one or more facets. Every slot has the value facet, which, unless initialized 
when the semantic net is initialized, is initially empty. However, the convention in Agent is that 
there are two other facets in every slot: the default slot and the if_needed slot. 

The default facet contains a value that is used if the value facet is empty. In general, rule 
bases to do alter the default facet. There is a value in the value facet and a rule causes that value 
to become empty, the inference engine will use the default value at its next opportunity, if there 
is a default value. | 

Finally, an “if needed” function belongs to the third standard facet. If the first two facets 
are empty, and there is a function in the if needed facet, that function will return a value. So 


when referencing a slot, the following order is used: 


1. value 
: default 
3: if needed function 


If the rules writer knows that the if needed function need only be called once, the 
following construct can be used: 
The temporary_value is the cost of THAT message 
where the “cost” is calculated with an if needed function. Then “temporary value” can 
be used until the cost needs to be recalculated. Using if needed functions is best when the value 


returned must be measured from a constantly changing world model. 
IF The distance from landing of the aircraft is_greater_than 20 miles 


In this case, each time the distance from landing slot is accessed, the if needed function 


provides the current answer. 
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DIRECTIVES 


Directives are special words which perform special actions in consequents of rules. They 
have a different syntax that ordinary consequents. Examples are DEINSTANTIATE, LOCK, 
UNLOCK, MOVE, INFER, etc. 


IF ANY message is late 
THEN DEINSTANTIATE THAT message FROM <frame> 


re DEINSTANTIATE 


DEINSTANTIATE <object> [FROM <frame>] performs the opposite action of “is_a” in 
a rule consequent. Instead of creating an instance or object, it deletes it. I know of no standard 
inference engine which allows deinstantiation, but we have to have it in order to get rid of 
messages that no longer have any value to Agent processing. 

The part of the consequent that follows the DEINSTANTIATE is parsed according to the 
normal grammar. So that, in the above case, “THAT message” refers to the subset created by the 
antecedent use of ANY. 

If no FROM clause appears, the object is removed from all of its is_a links. If a FROM 
clause appears, the object removed only from the listed frame. Thus an object, such as a 
message, can be instantiated in a temporary manner to a class, instantiated to one or more 


additional classes, and then removed from the instantiation list of the original “is_a” assignment. 


ze LOCK/UNLOCK 


LOCK <shared memory> | <class> | <object> | <variable> 
prevents all access to a sub-tree within shared memory, or to a named variable. Although 


LOCK can apply to any sub-tree, it generally applies to the whole of shared memory (which is a 
sub-tree of the null object) or to the instantiations of one or more messages. When other 


processes use a construction that accesses or changes a locked sub-tree, they can either hang 
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until unlock or fail. Hanging until unlock is easier to handle and understand than failure, so the 
design will cause the other processes to pause until unlock. 

One tricky part of LOCK/UNLOCK not shown in the rules below is that after the lock 
succeeds the rule has to be repeated because the lock of some other process could have 
succeeded before any given lock takes place. Thus the conditions that prompted the lock could 
no longer apply. Thus, if I locked an aged entry message, I could very well find out that some 
other process had marked it for encoding (so it was no longer an entry message). In practice that 
means that those messages identified by the ANY in an antecedent are no longer part of the 
THAT/THOSE of the consequents after locking. Which is why, after locking, the rule has to be 
repeated. These repeats are not shown in the rule sets developed for the engineering design for 


the sake of simplicity, but will be part of the detailed desi en. 


3. NUMBEROF 


NUMBEROF <frame> returns the number of instantiations (not classes) associated with 
that frame or any of its decendents. Thus 


NUMBEROF messages 
returns all of the messages that have been instantiated in the semantic network below the 


“message” frame. 


NUMBEROF THOSE messages 
will return the number of message as subsetted by previous ANY clauses. 


4. NAMEOF 


NAMEDOF is used to return the name(s) of instantiated object(s). There are times when it 
is important to refer to specific instantiations whose names may have been assigned and not 
stored. 

NAMEOF THAT message 

returns the true message name. NAMEOF is generally useful in conjunction with 


variables, as in 


name is NAMEOF THAT message 
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The status of $name is empty 


[If NAMEOF matches multiple names, then all are returned. 


5. INFER 


A rule base can initiate inferencing on another rule base, pausing until the inference 
engine concludes. This not only makes the rules easier to read, but also eliminates inferencing 
when it isn’t needed. When [NFER is completed, the facts instantiated by the call become part of 
the facts available to subsequent rules in the calling knowledge base. It looks like this: 


IF X 
THEN INFER knowledge-base 


It is assumed that the facts needed for the named knowledge base are the ones available 
to the calling data base (although the named knowledge base can trigger a function that generates 
additional facts, if it needs to). The resulting facts simply become available to subsequent rules 
and are returned to the calling base (or to the metarule level) as the results of the inferencing 


process. 


6. PARALLEL 


The PARALLEL directive allows certain rules to fire concurrently with other rules if the 
system has multiple processors available to it. The use of PARALLEL is discussed in the section 


below concerning automatic rule sorting. 


SPECIAL TERMS 


There are other terms, such as NULL, MINUS, TIMEf and FIELD that are like 


directives except that they are part of the normal rule syntax. 
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1. NULL 


NULL is used in facts and rules to erase any values assigned to a slot. 


The color of the house is NULL ONLY 
resets the value to the empty set. This usage is completely different and distinct from the 


null class to which all objects and instantiations are related. In general, if NULL follows “is a,” 
it refers to the null frame. In all other forms it refers to an empty value. 

Implementation is automatic in that if no value is assigned to a slot called “null” in the 
null frame, the result will be to return a null value. Expressions that would set a value into a slot 


called “null” are disallowed. 


Zs MINUS/PLUS/DIVIDED_BY (Slot Arithmetic) 


For example, in the construction, 


IF The status of ANY message is entry* 
The TIME minus the time of THAT message is_greater_than the 
message processing time_limit 
a slot reference appears on either side and a numeric value of the slot is expected. If the 
values in the slots are not numeric the antecedent simply fails. If they are numeric, then 
subtraction takes place and a value results . This value can be stored explicitly, as follows: 


The TIME minus the time of THAT message 1s the 
delay_time 
This expression puts the difference into the delay_time slot. 


The idea works for other embedded arithmetic operations on slots. There 1s however a 


different form of arithmetic in the rules, which is described below. 


3. FIELD 


FIELD (source or destination string, starting position, number of characters) 


* These rules cover the problem of an entry message (left or right) that has sat too long without being processed 
(encoded or decoded). 
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FIELD represents a substring delimited by a starting position and a number of characters. 
The source can be an input buffer or a slot value. The starting position starts at 1. If the number 
of characters field is set to zero, then the all available characters from the starting position to the 
end are matched and the number of such characters is returned in the third parameter. If the 
number of characters is set to a positive value, that number of characters 1s matched. Thus 


NCHARS = 0 
string of message is FIELD (left_input_buffer, 1 ,nchars) 
transfers the entire contents of the input buffer to the string slot of the message frame, 


and returns the number of such characters to the nchars parameter. 
In Agent initialization, the following statements might appear: 
A message format 1s a NULL_CLASS. 
A J3.2 is_a message_format 
The track-position of a J3.2 =is 14 
The track-length of a J3.2 1s 22 characters 

This declarative knowledge, stored in KIF format, is persistent knowledge. That 1s, it is 
not normally changed by consequents of rules as they are fired by the inference engine. They are 
usually part of the invariant part of the semantic net in shared memory. (The inference engine 
has the capability of dynamically changing persistent knowledge, which means that it is capable 
of learning, although Agent does not employ this feature.) 

In this way, with the use of field, any message can be decoded from its character string 
format (raw format) to a set of slot values within an instantiated object. The knowledge of how 
to do this 1s external to the agent, so that the agent can operate on any set of messages without 
changing its internals. The only assumption is that the message is in string format and the field 
positions are fixed. However, a version of Agent can be built that can deal with variable format 
messages as well as long as sufficient information is present in the message to be able to 


determine field starting positions (and, possibly, lengths). 


4. NCHARS 


NCHARS, which takes no arguments, returns the number of characters in the left or nght 
input buffer. 
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L. VALUE ARITHMETIC 


Simple arithmetic is allowed when setting slot values. For example, sometimes a counter 
needs to be incremented. For example, 


THEN The time of the message is the time of the message + 1 


takes the time of the message, adds one to it, and stores it back in the time slot. However, 
in this case the default 1s ONLY. There is another directive, called ALSO, which performs slot 
concatenation. This can be rather interesting if misused. If I write 
THEN The time of the message is the time of the message + | 
The time of the message is 23 hrs” 
Then I will have a single value for the time of the message, 23 hrs, because the parser 
interpreted these consequents as follows: 
THEN The time of the message is the time of the message + 1 ONLY 
The time of the message is 23 hrs” ONLY 
The second use replaced the first. If I had written 


THEN The time of the message is 22 hrs ONLY 
The time of the message is 23 hrs + 1 ALSO 
then 


IF The time of the message 1s 23 hrs 
The time of the message is 23 hrs + |] 
would succeed! Recall that in non-numeric value assignments the grammar defaults to 
ALSO. 
A special but important variation of value arithmetic takes the following forms: 
<slot> = <slot> <arithmetic operator> <value> | <slot> 
<slot> = <arithmetic expression> 
The following are examples of this form of arithmetic: 
C=C+] 
> The units after a value are stored but ignored. If the right-hand side of a consequent is can be interpreted as a 
numeric operation, it will be. Any characters after the numeric are considered to be something like units, stored 
but unevaluated. 
° The units after a value are stored but ignored. If the right-hand side of a consequent is can be interpreted as a 


numeric operation, it will be. Any characters after the numeric are considered to be something like units, stored 
but unevaluated. 
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C= 23.5/1 


Thus counters can be employed as needed. Note that the slot reference is in the null 


object or frame, and that ONLY is implied. As written, these counters are global. 


M. CONCATENATION IN NAMES 


The use of square brackets denotes concatenation. In Agent, concatenation is used to 
produce an unique identifier for an object. Thus, 
n=n+l 
message[n] is_a update 
increments the counter, concatenates the value of that counter to the string “message,” 
and instantiates the object under the concatenated name. This is more of a bookkeeping facility 
than a necessary one, in that one could design the semantic network to have multiple objects of 
identical names, but it results in a difficult design with no advantage. Once the message has been 
instantiated as message[n], other rule sets will pick it up or ignore it on the basis of the values in 


its slots rather than by its name. 


N. VARIABLES, POINTERS, AND INDIRECTION 


Although the use of slots in the null frame is rather helpful, coordinating asynchronous 
processes requires some kind of local variables in the rules. For example, in the example in the 
section above, n is a slot of the null frame. However, if two identical processes are operating, 
they will not be able to use this mechanism easily. Therefore any identifier that begins with an 
ampersand becomes a local variable available only to the rule base in which it appears. 

&n = &n+ | 
message[&n] is_a update 

In this case, local space, space not in global shared memory, is allocated for n, and that 
allocation is only available within the scope of the process that defines it. Within the operations 
of that process, n is global. That is, it retains its value once assigned. In some sense it is a 


permanent variable outside of the scope of the semantic network. 
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Any structure can be stored in such a variable, including messages. The inference engine 
evaluates the variable to a structure or a value and substitutes that structure or value in the rules. 
If, however, I assign a complex structure, such as a message, to a variable, a copy of the original 
is created. The original itself is untouched. 

The pound sign 1s used for pointer variables. One can write, for example, 


#n 1s message[n] 


In this case the pointer refers to the original message and not to a copy of it. 
The dollar sign (“S$”) is used to indicate indirection. For example, if I use a slot in the 


null frame to store the name of an object I have no way of getting to the contents of that object. 


THEN n 1s message[m] 
The status of n is idle 


The first use of n is as the “n” slot of the null frame. The problem here is that in the 
second line “n” is meant to be the value of the n slot of the null frame (which is a message). A 
slot cannot have a slot. Therefore, to indicate that I want n to be evaluated before the rest of the 
expression, I use a dollar sign: 


THEN n 1s message[m] 
The status of $n is idle 
The inference engine effectively substitutes “message[m]” for “n” in this case, since 


“message[m]” is the value of n. 


O. REASONING WITH UNCERTAINTY 


Although there are many forms of reasoning with uncertainty that can be explicitly added 


to the consequents of production rules, none are required in this application. 


THE AGENT ENGINE 


The inference engine must be custom built for this project. In addition to the 


constructions documented in other parts of this document, it will have other components 
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important to real-time efficiency and embedded applications (in this case, operating to support 


an intelligent agent). 


1. Rule Order and the Academic Paradigm 


The tradition has been that rules can be added to knowledge bases as they are constructed 
without regard to the concepts we normally think about in “structured programming.” In fact, 
relatively arbitrary rule ordering and entry (via rule editor) is often seen as a virtue. To make this 
feature possible, inferences engines repeatedly cycle through the rules until one complete pass is 
made in which no new inferences are made. Given a pathological rule ordering, this strategy can 
make inferencing very slow, which cannot be tolerated in a real-time application. 

Nor is it necessary. The rules in the Agent Inference Engine are ordered (normalized) so 


that a slot in an antecedent never appears before its uses as a consequent. Thus the rule order is 


always 

IF A 

B 
THEN C 
IF C 
THEN D 

and never the reverse: 

IF C 
THEN D 
IF A 

B 
THEN C 


In the first case the inference engine examines the two rules and quits. In the second case 
it has to process the rules three times: the first time fires the second rule, the second time fires 
the first rule, and the third time fires no rule (and, so, terminates inferencing). A complex 
knowledge base can therefore be either expensive or cheap depending upon the ordering of the 
rules. Other than tradition, there is no argument in favor of arbitrary rule ordering. It is simply a 
bad idea. 
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Secondly, ordered rules are much easier to read. There is no reason why rules cannot be 
read from top to bottom in a single pass—which is the well-proven idea behind structured 
programming. Easy to read, easy to maintain, less apt to have bugs. Importantly, it is much 


easier to tell when a rule set is complete when it is normalized. 


2. Automatic Rule Sorting and Parallel Processing 


Note that recursion can span over many rules making it difficult to spot. For this reason, 
in the final implementation, the rule editor associated with Agent will automatically sort the 
rules, in normalized order, and detect any circularities in the process. This is not a trivial thing in 
that rules can recursively activate the inference engine on other rule bases that can instantiate 
facts that create recursions (or affect the rule ordering). 

A certain subset of the rules being sorted must occur in normalized order. On the other 
hand, there can be rules between elements of the subset in which the order is irrelevant. These 
rules may be tested for firing concurrently if multiple processors are available. The rule sorting 
mechanism can insert the directive PARALLEL before a group of such rules, and END 
PARALLEL after them. The inference engine can then send each of the rules between the two 
directives to special instantiations of itself operating on different processors. The END 
PARALLEL directive pauses if not all of the rules in a parallel section have been examined. The 
result is a much faster engine, better suited to real-time applications. In general a long rule base 


will have many such opportunities for parallel processing. The sorter makes them automatic. 


5: Functions Within Consequents 


Another great benefit of normalizing rule bases is that effector functions can be used in 
the consequents of ordinary rule bases, knowing that they will take action predictably (that is, a 
function in a rule will be invoked before a function in a subsequent rule). Thus the Agent 
inference engine can not only recognize situations, but it can also safely take action to alter 


things outside of itself. 
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4. Nested Inferencing 


As mentioned in the description of the INFER directive, knowledge bases can call other 
knowledge bases. This nesting can be taken to any depth, as needed. The idea is to partition 
knowledge bases for clarity and efficiency. For example, a call to INFER presumes various 
facts, so that the rules being activated to not have to test for their truth. They simply assume that 
if they are being activated, certain conditions hold. This makes for much simpler rules. For 
example, within the confines of a Link 16 network, bandwidth availability, as dictated by the 
spread spectrum architecture of a given network configuration, places limitations upon the 
volume of data, and periods of transmission and receipt. To that end, the INFER in this instance 
is that the Agent is to process all information, and forward, without regard to the Link 16 
constraints. Another portion of the Link, is available to carry out the required network 


transmission / receipt functions. 


5. Compiling 


Rule sets can be compiled in the Agent system or they can be run interpretively. The 
reason rules can be compiled is that slot references for all dynamic objects are fixed (or can be, 
if modifications to the class structure of the semantic network during run time are disallowed). 
Without compilation, in order to find a message instance it is necessary to search through the net 
starting with the null object. Once compiled, however, the inference engine can go directly to the 
instantiations. Any null object slots that are predefined can also be referenced in this way. Slot 
items that are defined during run time require dynamic look up. 

The advantage of interpreting the rules is that a standard validation mechanisms can be 
used, such as automatic rule tracing and query (e.g., “Why did Agent force transmission of that 
message when it did?”). The compiled version has no such features and is designed solely for 
efficiency. Thus the interpreted version is used for building and debugging, while the compiled 


version is used in the fielded versions of Agent. 
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6. The WHILE Construction 


There are times when it becomes necessary to have the inference engine iterate over a set 


of rules in a knowledge base. The WHILE construction allows this. Its form is as follows: 


WHILE <truth expression> 
BEGIN [name] 

<rules> 
END {name] 


While the expression remains true (e.g., “The house is red’, “The value is_greater_than_ 
10”), the rules between BEGIN and END are iterated. An EXIT appearing within the scope of 
BEGIN and END causes the WHILE to be retested—it does not exit to the meta controller. 

The WHILE construction can be nested indefinitely for complex processing. In Agent, 
where many updates can be bundled within a single Agent message, the WHILE construction 
enables a single set of rules to decode all of the updates without having to return to the meta 
language level. 

The name on BEGIN or END 1s entirely optional. Its use enhances readability. However, 


if a name is given on the BEGIN the identical name must be given on the corresponding END. 


oy. BREAK 


BREAK [string] causes a jump to the test of a WHILE statement, or an exit from a 
knowledge base to the meta level if not within a WHILE statement. The string is optional (for 
readability). 


Q. SHARED MEMORY 


Shared memory references that common memory utilized by an Agent on a singular 
node. The processes of an Agent communicate through global, shared memory (RAM). Both 
persistent and perishable knowledge is stored in shared memory. Persistent knowledge is created 
at initialization with a special form of facts, while perishable knowledge is created by the firing 


of rules during inferencing. 
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There are many uses of shared memory. For example, shared components of the 
architecture maintains the operating mode, network loading factors, and encoding scheme in use 
in shared memory. The Shared Component is the only process that sets these slot values within 
shared memory. All other components simply reference them. 

Also, if there are multiple processors operating, any available processor in the delta 
components can take responsibility for processing a given entry message simply by locking it 
and changing its status. 

Since output messages to the terminal must be batched (since the terminal normally sends 
three or six word transmissions), there exists a single output message object that all processors 
share. Each contributes a delta update until the message is long enough for effective 
transmission. | 

Various locking mechanisms, described above, make this sharing possible through a 
crude form of synchronization. Shared memory resembles a blackboard structure when multiple 
processors are involved, because each scans shared memory to determine what to do. 

Far example, an output process constantly looks for messages with status “output.” 
(There is one output process for each direction (to terminal, to host).) Two antecedents are 


enough. In the following case, the night output processor selects its messages: 


IF The status of ANY message is output 
The direction of THAT message is right 
THEN LOCK that message 


THAT message is_a output_message 
DEINSTANTIATE that message FROM temporary_message 


META CONTROL AND META LANGUAGE 


As will be shown in the detailed descriptions below, the meta language is generally rather 
simple in implementation. Agent has been designed to minimize the complexity of the meta 
language needed to drive it. 

The metalanguage is interpreted and is loaded into Agent at initialization time. 

A small run-time kernel for each process is needed to interpret and execute the meta rules 


for that process. 
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i. Meta Control Functions 


a. LOOP 

(LOOP (<fact>) (<factset>) (<scope>)) 
Repeatedly executes the scope as long as the fact 1s true in the factset. 
b. EVENT 


(EVENT (<fact>) (<scope>)) 


EVENT executes the scope whenever the fact ts true in the default or global factset. This 
is a way that system events (such as “shut down” ) can affect running processes. EVENT differs 
from LOOP, in that EVENT 1s triggered by “true” condition in the default, or global factset. 
LOOP is a directed (program) statement, which will execute when directed, and continue 


execution as long as the determining fact 1s true. 


Cc. INFER 


(INFER (<knowledge base>) (<input facts>) (<output facts>)) 


INFER causes the knowledge base specified to be processed using the input facts. The 


result of the inferencing process is the set of output facts. 


d. EXIT 


(EXIT ) causes the process to terminate. 


é. CREATE 


(CREATE (<factset>) (<factsetname>)) 


CREATE explicitly creates a factset with the name supplied. Factsets are also created 


implicitly be reference. 
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fi RELEASE 


(RELEASE (<factset>)) 


This deletes the named factset. 


g.  ADDFACT 


(ADDFACT (<fact>) (<factset>)) 


Adds a fact to a factset. 


h. DELFACT 


(DELFACT (<fact>) (<factset>)) 


Removes a fact from a factset. 


i, | IS TRUE 


(IS_TRUE (<fact>) (<factset>)) 


Returns TRUE if the fact is true in the factset. 


j. _ IS_FALSE 


(IS_FALSE (<fact>) (<factset>)) 


Opposite of TRUE. 
k, IF 
(IF (<truth function>) (<scope>)) 


IF executes the scope when the truth function evaluates to true. Generally, this will be 


seen as follows: 


(IF (TRUE (<fact>) (<factset)) (<scope>)) 
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L MERGE 


(MERGE (<factset1>) (<factset2>) (<factset3>)) 


Causes the facts from factsetl to be combined with the facts in factset2 to form factset3 
(which can be the same name as either of the first two sets). If a fact is true in either factset1 or 
factset2 then the true fact is in the output factset3. If both factsetl and factset2 are true, both 
truths are added to the output factset3. If neither factsetl or factset2 are true, then this instance 


of the merge produces a null output, or no merge for this fact only. 


m. EFFECT 


(EFFECT (<function>) (<parameter list>)) 


EFFECT calls the function given with the parameter list given. This is a catch-all for 


any function that is useful. 
n. NOTIFY 
(NOTIFY (<string>)) 


Sends a string to the operator console. 
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Figure 20, Agent Architecture 
LINK MANAGER 


The Link Manager enforces the time rules of the network, as well as performing 
housekeeping functions for Agent. If only the Shared Message Structure and the Link 
Manager existed, the network into which Agent was inserted would function normally. 
Messages would be intercepted from the left (host) or right (terminal), be placed into the 


structure, age, and then be asserted on the output network or bus in the correct direction 


(that is, to the host or to the terminal). 
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Figure 21, Link Manager 

Agent, at the physical level, is a severance implementation. That is, the network 
or bus between the host and the terminal are physically severed, and the Agent hardware 
is inserted at the severance point. The software functions by interception. Messages 
coming in either direction are intercepted by Agent, processed, and then asserted back on 
the network or bus. The messages may be asserted in their original form or in Agent 
format. If repetition rate reduction is in effect, outgoing messages (that is, messages from 
the host to the terminal) can be deleted by Agent. 

Each of the components of the Link Manager is a separate process. They may 
very well be implemented on separate processors, in order to meet run time requirements. 
They all operate asynchronously, communicating indirectly through the Shared Message 
Structure. 
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SIMPLIFYING ASSUMPTIONS FOR THE PROTOTYPE 


It is assumed that J-Series messages of types 3.2 (air track), 3.3 (surface track), 
and 2.2 (Air PPLI) are of interest—all others are not. This assumption, as, indeed, all 
other assumptions, is entirely rule or fact driven and not internal to Agent. 

It is assumed that there is a fixed-length message header in all outgoing messages. 
It is assumed that the type of message is in this header as well as in the message itself. 

The time the message was originated is presumed to be in the header. There is 
also a field in the header that indicates that an outgoing message must be acknowledged. 
However, this field is ignored at this time because none of the types processed require 
acknowledgment. If a type is at some point handled that does require acknowledgment, it 
can simply be passed through as is (it is presumed that such messages are a rare 
occurrence). 

For simplification, each J-Series message is presumed to be the same length. Each 
contains the following fixed-length fields: 

eMessage Type 

eTrack Number 

eUpdate Time 

eLatitude 

eLongitude 

Of course, real messages have considerably more fields than this. However, they 
would be handled in precisely the same way as the identified fields. It is presumed that 
the field positions within the three update types of interest are identical. 

The “Update Time” field refers to the time of the observation or update, not the 
time the message was originated or the current time. It is also presumed that the time in a 
series of these updates is predictable plus or minus a small delta. Therefore an Agent, 
looking at the last few update messages, can determine if it has a complete recent 


sequence from these times. 
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Le Left Input Process 


The left input process is alerted to the arrival from the host of a message. It has 


the following responsibilities: 


eReceives event notification from system I/O handler (left side) 


eDetermines message type 


eInstantiates the message in shared memory 


elf of an interesting type (e.g., one that will eventually be transmitted in raw or 


Agent 


form by the terminal) it sends it to the Message Store 


eSets the direction to “left” 


Sets the status slot to “entry” 


a. Production Rules 


This knowledge base is identified as “LeftInput.” It requires no facts except the 


event type (it doesn’t actually need the event type either, if the only event type it handles 


1S new Message). 


IF 
THEN 


ELSE 


Event 1s new_message 

LOCK n’ 

n=n+ 1 

UNLOCK n 

message[n] is_a message® 

&nchars = 0 

The string of message[n] 1s FIELD 
(left_input_buffer,1,&nchars)’ 

Type of message[n] is FIELD (string of message[n], 
position of type, size of type) 

EXIT 


’ There are three processes that can create new messages, and all must use unique names to do so. 
Therefore they all use the global slot “n” to do this. If the vaniable is already locked the process hangs 
until the variable is unlocked by the locking process. 

* Until we know what type of message we’re handling, it will be instantiated simply as a “message.” 
Later, it will be instantiated properly (using multiple instantiation), then deinstantiated from message (so 
that we won’t have multiple links to the same message in the same subtree of the semantic network. 
"When the third argument to FIELD is null or zero, this is a signal for FIELD to retum the number of 
characters transferred from a system routine. When the third argument is positive, it specifies the number 
of characters FIELD will return. In this case we are interested in the entire message, so nchars is set to 
zero before the call, insuring that all of the input data will be transferred. 
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IF The FIELD (type of message[n], 1, 1) is “J’!° 
THEN The class of message[n] is interesting ONLY 
ELSE The class of message[n] is uninteresting ONLY 
The type of message[n] is housekeeping 
Message[n] i1s_a output_message 
The direction of message[n] is right 
The status of message[n] is output 
DEINSTANTIATE" message[n] FROM message’” 


IF (The type of message[n] is J3.2 OR 
The type of message[n] is J3.3 OR 
The type of message[n] is J2.2) 


THEN The interest of message[n] is targeted ONLY 
ELSE The interest of message[n] is not_targeted ONLY 
iif The interest of message[n] is targeted 

THEN Message[n] is_a track update” 


DEINSTANTATIATE message[n] FROM message 

The message_time’’ of message[n] is FIELD (string of 
message[n], position of message_time, size of 
message time) 

The update time’ of message[n] is FIELD (string of 
message[n], start of time, size of update_time) 

The track of message[n] is FIELD (string of message[n], 
position_of_track, size of track) 

The lat of message[n] is FIELD (string of message[n], start 
of latitude, size of latitude) 

The lon of message[n] 1s FIELD (string of message[n], 
start of longitude, size of longitude) 

The header of message[n] is FIELD (string of 
message[n],1, size of header) 


'° Using quote marks ensures that the comparison will be to the character J. Otherwise the comparison 
would be to the value found in the J slot of the null frame. 

'’ Recall that this DEINSTANTIATE removes the message only from the class message. It has also been 
instantiated as a track update message and is not removed from class track update. IF there had not been 
multiple instantiations, the message would have been deleted by DEINSTANTIATE. 

'? Note that we did not instantiate this message as a “housekeeping message” because, unless the actual 
implementation gets into buffer management, housekeeping messages mean nothing to Agent 

'> Although we could retrieve the message type using FIELD, we already know it has to be “update” 
because of the J-series type. 

'* The “message time” is the time in the message header used for host-terminal bookkeeping and 
checking. 

'® The “update time” is the time of the sighting, as produced by surveillance processing. It is separate and 
distinct from the message time. “At update time X vehicle Y was at position Z, and the mssage was 
created/sent/originated at message time A” may demonstrate the difference in meaning. 
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The direction of message[n] is left 

LOCK J’ 

J=J+1 

UNLOCK J 

message[j]'’ is a raw_stream 

The size of message[j] is &nchars - headersize_out'* 
The message_time ofmessage[]j] is the message_time of 


message[n] 
The status of message[n] is entry”” 
EXIT 
IF The class of message[n] is interesting 
The value of message[n] 1s not_targeted 
THEN Message[n] is_a output_message 


DEINSTANTIATE message[n] FROM message 

The direction of message[n] 1s nght 

LOCK J 

J=J+1 

UNLOCK J 

message[j] 1s a raw_stream 

The size of message[j] is &nchars - headersize_out 

The message_time ofmessage[j] is the message_time of 
message[n] 

The status of message[n] 1s output 


b. Meta Rules 


(LOOP (EVENT” (“Left Input Message”)) 


( 
(INFER (“Event is new_message’’) (“LeftInput”) 


(“OutFacts”)) 


'6 J has to be locked because the right input process and the decoding processes create such objects and 
all have to be unique. Naturally, all processes that create history records use J. 

'7 Case is ignored in Agent. Case can be used in the facts and rules to make them easier to read. 

'8 J-Series messages can be of several different lengths. The header is of fixed length for all host-to- 
terminal messages. If the trigger is supplied by operating system elements or Gateway, and the number of 
characters in the input buffer can be known, then Agent does not have to keep track of the size of each 
message type. On the other hand, if the input components do not tell the size of the message, then input 
facts must supply the length in characters of each formatted message. 

'? All other processes are concerned primarily with the status of a message. Until the status slot is set, no 
other process will touch the message being built. As soon as that status is set the rule bases of other 
processes may operate on the message. 

° EVENT waits until triggered by a system process, Gateway, or other process. 
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ee Left Output Process 


The left output process asserts messages on the network connection leading to the 


host computer system. For Link-16, these are known as TOMs (Terminal Output 


Messages). Agent messages can also be sent to the host by this process. For other digital 


networks where a severance implementation is appropriate, these are messages 


originating from the nght side. 


a. Production Rules 


THEN 


THEN 


EESE 


IF 


The status of ANY message is output 
The direction of THAT message is left 
&pos = | 


The message of THAT message is to_be_ constructed 

The type of THAT message is J-Series 

The string of THAT message is NULL 

The string of THAT message is FIELD (the string of 
THAT message, &pos, MAKEHEADER())”’ 

&pos = &pos + size of right_header 

The FIELD (the string of THAT message, &pos, the track 
of that message) 

&pos = &pos + size of track 

The FIELD (the string of THAT message, &pos, the lat of 
that message) 

&pos = &pos + size of lat 

The FIELD (the string of THAT message, &pos, the lon of 
that message) 

&pos = &pos + size of lon 

The FIELD (the string of THAT message, &pos, the 
update time of that message) 

The status of THAT message 1s old 

The message of THAT message is constructed ONLY 

EXIT “Error—Can only construct update messsages” 


The message of THAT message is constructed 


*! In Link-16, there is a five word header on TOMs, or Terminal Output Messages. MAKEHEADER 
creates this legal header. Since the contents of the headers of both TIMs and TOMs is classified, this 
function, or, most probably, knowledge base, has been omitted. 
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The type of THAT message is_not J-Series” 

THEN FIELD (left_output_buffer, 1, size of THAT message)” 
TRIGGER (left_output_buffer, &pos)”* 
EXIT 


IF The message of THAT message 1s constructed 
THEN LOCK J 
J=J+1 
UNLOCK J 
message[j] 1s_a raw_stream 
The size of raw_stream[j] 1s SIZE (string of THAT 
message)” - headersize_in”® 
The message time of raw_stream[j] is the message_time of 
THAT message 
FIELD (left_output_buffer, 1, size of THAT message)” 
TRIGGER (left_output_buffer, &pos)”* 


BE Exception Handler 


The exception handler has several responsibilities. First, 1t must see that messages 


that have been delayed too long by Agent (too long as defined in the facts) are properly 


” Therefore it has to be an housekeeping message. 

3 The FIELD function now moves the message string, which will look to the host as if it were a standard 
message, to the system (or Gateway) output buffer. 

** TRIGGER tells the system that the buffer specified by the argument is ready for insertion on the bus or 
network connection on either side of Agent. The second argument is the size of the message. These 
arguments are notional in that the specific steps and forms will be determined for Agent during detailed 
design for a particular installation. 

SIZE returns the number of characters found in its argument. SIZE must be used carefully where values 
are subject to concatenation. In general, if there are multiple values, SIZE returns the length of only the 
first value. 

*°The header of an “in” message refers to the header of a message from terminal to host. The header of an 
“out” message refers to the header of a message going to the terminal. J-Series messages can be of 
several different lengths. The header is of fixed length for all host-to-terminal messages (currently 10 
words) and terminal to host message (currently 5 words). If the trigger is supplied by operating system 
elements or Gateway, and the number of characters in the input buffer can be known, then Agent does not 
have to keep track of the size of each message type. On the other hand, if the input components do not 
tell the size of the message, then input facts must supply the length in characters of each formatted 
message. 

7 The FIELD function now moves the message string, which will look to the host as if it were a standard 
message, to the system (or Gateway) output buffer. 

’® TRIGGER tells the system that the buffer specified by the argument is ready for insertion on the bus or 
network connection on either side of Agent. The second argument is the size of the message. These 
arguments are notional in that the specific steps and forms will be determined for Agent during detailed 
design for a particular installation. 


He 


forwarded within allowable time limits. Second, it looks for “collisions,” which occur 
when an update on a track is received before a pending update has reached output status. 
A collision forces the pending message to be sent immediately (with all of the other 
messages thus far batched with it). Finally, it “prunes” the shared message structure of 


message so old as to no longer be of interest. 


a. Production Rules 


Rules for the exception handler are central to the overall design of the rule bases. 

The first is a message whose status has stayed “entry” too long (the “Aged Entry 
Message”). Because its status is “entry” it is not either now or soon to become a 
component of the temporary_message or the output_message. Therefore it is instantiated 
as an output_message and otherwise deinstantiated. 

If the status of a message is “encoding,” then some process has either already 
added it to the temporary_message or will soon do so. The exception handler will output 
the temporary message if the ID is there. Otherwise it does nothing at this point because 
one of the processes will soon add the ID to the temporary message. If the entry is idle 
for too lond a period of time, as determined by network rules of operation, the message, 
upon updating of the temporary storage buffer, will have the appropriate ID established, 
and transmitted. This is not an arbitrary process, but rather a trade off between the desire 
to maximize thje fill of each transmitted packet, v.s. the time constrains of transmission. 
At a subsequent inferencing, that rule base will find the ID in the temporary message and 
force that message to be sent. 

The third exception has to do with an update arriving for the same track that is 
currently being processed. In this version of the rules, the base forces the output of the 
temporary message and allow the new update to be processed normally. 

Old messages that are no longer of value to Agent are pruned so that the space 
can be made available for additional messages. This store of old message is used by 
various heuristics to construct or deconstruct Agent reduced messages. 

Finally, objects which are used to determine network and NPG loading are 


purged after they are no longer useful in determining net and node saturation levels. 


73 


(1) 
IF 


THEN 


THEN 


THEN 


Aged Entry Message 


The status of ANY message is entry” 

The direction of THAT message 1s left 

The type of THAT message 1s track_update 

The TIME f*’ minus the message_time of THAT message 
is greater than the update_processing_limit 

LOCK THAT message 

The status of THAT message 1s output 

The direction of THAT message is right 

The status of THAT message 1s old 

The message of THAT message is constructed ONLY 

UNLOCK THAT message 


The status of ANY message is entry 

The direction of THAT message 1s right 

The type of THAT message 1s track_update 

The TIMEf minus the time of THAT message 
is_greater_than the update_processing_limit 

LOCK THAT message 

The status of THAT message 1s output 

The direction of THAT message 1s left 

The status of THAT message 1s old 

The message of THAT message 1s constructed ONLY 

UNLOCK THAT message 


The status of ANY message is entry 

The direction of THAT message is right 

The type of THAT message is housekeeping 

The TIME f minus the time of THAT message 
is_greater_than the housekeeping processing limit 

LOCK THAT message 

The status of THAT message is output 

The direction of THAT message is left 

The status of THAT message is old 

The message of THAT message is constructed ONLY 

UNLOCK THAT message 


The status of ANY message is entry 
The direction of THAT message is right 
The TIME/ minus the time of THAT message 


*® These rules cover the problem of an entry message (left or right) that has sat too long without being 


processed (encoded or decoded). 


*° This is the current system time (or other appropriate time reference). 
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is_greater_than the general_processing limit’ 
THEN LOCK THAT message 
The status of THAT message is output 
The direction of THAT message is left 
The status of THAT message is old 
The message of THAT message is constructed ONLY 
UNLOCK THAT message 


(2) | Aged message being encoded” 


IF The status of ANY message is encoding?“ 
The TIME minus the time of THAT message 
is _greater_than the general_processing limit® 
THEN LOCK THAT message 
LOCK the temporary_message 
The status of THAT message is late 


IF The status of ANY message is late 
The track of THAT message is the same _as the track of 
the temporary message 
THEN LOCK shared memory 
The status of THAT message is old 
The temporary_message is_a output_message 
gpos = 0°° 
DEINSTANTIATE THAT message from 


*! The processing time limits have not been determined. It is probable that all J-Series messages will have 
the same time limit, and, perhaps, the housekeeping messages as well. On the other hand, they could be 
different. If so, each message type may have a time limit associated with it and these rules must be 
expanded accordingly. 

* Note that aging messages being decoded cannot be handled as exceptions because there is nothing 
Agent can do but continue to decode them. Until it decodes the message it cannot even be aware of which 
tracks are involved, and therefore cannot sense track collision (new update arriving before old update is 
processed). On the other hand, decoding is one of the fastest processes. The processor must be specified 
so that all messages are decoded fast enough so as not to be considered late. 

*’ These rules handle the case where it is taking too long to batch various messages for output. What will 
happen is that the temporary message, which is where all processes assemble batched messages, will be 
output as is and the original messages that are part of that temporary messages will be deleted from 
shared memory. This will result in a message with fewer updates than is possible, but ends any further 
delays. 

* Tf the status is “encoding,” and it is true that the message originated from the left (host) side, and Agent 
is presently operating with reduction, compression, or both. Since all reduced updates must be batched, 
the results of this encoding appear in the temporary message. 

*° Additional rules may be needed if the processing times are different, as explained in a previous 
footnote. 

*° Gpos is a global counter used by the encoding heuristics to mark the next available place in the string 
of the Agent message being constructed. When a message is deinstantiated from the temporary message 
class, then this counter must be reset. Since the whole of shared memory is locked at this point, no 
special lock is required. 
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THEN 


(3) 
IF 


THEN 


THEN 


THEN 


temporary_message 
UNLOCK shared memory 
UNLOCK THAT message 


The status of ANY message is late 

The track of THAT message is_not the track of the 
temporary message 

CONTINUE” 


Collision 


The status of ANY message is entry 

The track of THAT message is the same_as the track of 
the temporary_message 

The direction of THAT message 1s left 

LOCK THAT message 

LOCK the temporary message™ 

The direction of the temporary message is nght 

The temporary_message 1s_a output_message 

The status of THAT message is old 

gpos = 0 

UNLOCK THAT message 

DEINSTANTIATE the temporary_message 


The status of ANY message 1s entry 
The &track is the track of THAT message 


The status of ANY message is encoding 

The track of THAT message is the track of the 
temporary_message”’ 

The track of THAT message is &track”° 

LOCK the temporary message” 

The direction of the temporary message 1s night 

The temporary_message is_a output_message 

gpos = 0 


*” If the track ID isn’t in the temporary message now, it will be shortly. The problem will be caught on a 


subsequent iteration of the rules. 


*’ The temporary message class is only used for messages being encoded. Therefore the direction will 


always be nght. 


*» Added last deliberately for the purpose of having this test work. 

*° We’re looking here for an update to a track that is already being encoded. We can detect this because 
the track number 1s in the temporary message. This means that the track number is also in a message 
labelled encoding. And a new update has arrived. Therefore the action is to force out the temporary 
message before processing the new update. 

*! The temporary message class is only used for messages being encoded. Therefore the direction will 


always be nght. 
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The status of THAT message is old 
UNLOCK THAT message 
DEINSTANTIATE the temporary_message 


(4) Message Pruning 


IF The status of ANY message is old 
THAT message is_a track update” 
The NUMBEROF*(THOSE messages) is_greater_than 
one“ 
The TIME of ANY message minus the time of THAT 
message is_greater_than the persistence_limit*° 
THEN DEINSTANTIATE THAT message“ 


(5) | History Record Pruning 


IF If the TIME/ minus the time of ANY history_record 


is greater than 2 * net_frametime 
THEN DEINSTANTIATE THAT history_record 


b. Exception Handler Meta Rules 


Metarules are designed to be simple, and, in the case of the Exception Handler, 
they are very simple indeed. There is one knowledge base, called “exceptions,” detailed 
in the section above. All the meta rules do is loop on this knowledge base. 


(LOOP () 
( 


) 


This data base is interesting because it requires no input fact list (it merely needs 


(INFER () (“exceptions”) (“OutFacts”)) 


access to Shared Memory), and that it has no use for the output facts it produces. The fact 
that the input FactSet is null means that each time it 1s executed the old facts generated 
through inferencing are gone.The purpose of the data base, in this instance, is to provide 


the unique knowledge reservoir of the associated network(s) principles of operation. In 


*? Other types of messages (e.g., housekeeping, Agent) are pruned when decoded or encoded. 

*? NUMBER returns the number of objects instantiated to the class mentioned. 

““ The first ten numbers are defined as their value in the null class for readability. 

*° The persistance limit is how long we need to keep old messages before they no longer have value. At 
this point a function could be added to archive the messages about to be deinstantiated. 

“ This is an example of subsetting. The set of messages identified by the first use of ANY is further 
subsetted by the second ANY, so that the DEINSTANTIATE directive only applies to the smallest subset 


ay 


this way the Exception Handler can be designed in such a manner as to be independent of 
specifics, with respect to a particular network’s rules of operation, while providing 
unique capability in each instance. 


Of course, other actions can be added, such as logging functions, as desired. 


C. Right Input Process 


The right input process accepts messages from the terminal or right side. If they 
are standard messages they are simply marked for output after keeping track of the 
implied network loading. If they are Agent message they are marked for decoding after 
keeping track of the amount of data (bits) that were transmitted over the RF network. 


(1) Production Rules 
The name of this knowledge base is “InputRight.” 


IF Event is new_message 
THEN LOCK m 

m=m+1 

UNLOCK m 


message[m] 1s _a message 
The type of message[m] 1s FIELD (type_position of 
right_header, size_of_type of right_header) 


IF The type of message[m] is housekeeping 
THEN The string of message[m] is FIELD (right_input_buffer, 1, 
update_size) 


The direction of message[m] is left 

The message of message[m] is constructed 
The form of message[m] is raw 

The status of message[m] is output 


EXIT 
IF The FIELD(type of message[m],1,1) is “J” 
THEN The type of message[m] is J-Series”’ 
IF (The type of message[m] is J3.2 OR 


The type of message[m] is J3.3 OR 
The type of message[m] is J2.2 OR) 
THEN Message is interesting ONLY 


*” Recall that slot assignment implies concatenation for non-numeric values. Thus the message type is 
both “J-Series” and its original type (e.g., J3.2, J3.3, or J2.2). 
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ELSE 


THEN 


THEN 


THEN 


Message is uninteresting ONLY 
The form of message[m] is raw 


The type of message[m] is Agent 
Message is interesting ONLY 
The form of message[m] is encoded 


Message is uninteresting 

The direction of message[m] is left 

LOCK J 

J=J+1 

UNLOCK J 

message[j] is_araw_stream 

The rawsize of message[m] is (SIZEOF (string of 
message[m]) - headersize_out) 

The time of message[m] is FIELD (string of message[m], 
start of update_time, length of update_time) 

The message of message[m] is constructed 

The form of message[m] is raw 

Status of message[m] is output 

EXIT 


Message is interesting 

Type of message[m] is Agent 

Message[m] is_a Agent_ message 

DEINSTANTIATE message[m] FROM message 

The string of message[m] 1s FIELD (right_input_ buffer, 1, 
update_size) 

The encoding scheme* of message[m] is FIELD 
(right_input_buffer, position of scheme, size of 
scheme) 

The message_time of message[m] is FIELD 
(right_input_buffer, position of message_time, size 
of message_time) 

The direction of message[m] is right 

The form of message[m] is encoded 

The status of message[m] is entry 

LOCK J 

J=J+1 

UNLOCK J 


*® The Agent encoding scheme appears either in the message header, if possible, or in the encoded 
message itself. If the latter, then the first part of the message information is not incoded. This enables the 
receiving node to decode Agent-encoded messages without have to be syncronized with the sending node 
as to what scheme is being employed. 
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message[j] is_a encoded_stream 
rawsize of message[j] is SIZEOF (string of message[m]) - 


header_in 
time of message[j] is message_time of message[m] 
EXIT 
IF Message is interesting 
Type of message[m] 1s J-Series 
THEN The type of message[m] is_a track_update 


DEINSTANTIATE message[m] FROM message 

The string of message[m] is FIELD (nght_input_buffer, 1, 
update_size*’) 

The message_time of message[m] is FIELD 
(right input buffer, position of message_time, size 
of message_time) 

The track of message[m] is FIELD (right_input_buffer, 
position of track, size of track) 

The lat of message[m] is FIELD (nght_input_buffer, start 
of latitude, size of latitude) 

The lon of message[m] 1s FIELD — start 
of longitude, size of longitude) 

The update_time of message[m] 1s FIELD 
(night _input_buffer, start of update_time, size of 
update_time) 

The header of message[m] is FIELD (nght_input_ buffer, 
start of header, size of header) 

The direction of message[m] is nght 

The status of message[m] 1s output 

The form of message[m] is raw 

LOCK J 

J=J+1 

UNLOCK J 

message[j] 1s_a raw_ stream 

rawsize of message[j] is SIZEOF (string of message[m]) - 
header _in 

time of message[j] is message _time of message[m] 

EXIT 


(2) Meta Rules 


(LOOP (EVENT (“Right input message’’)) 
( 


*? This assumes that all three update types of interest are the same length. If they are of different lengths 
then there has to be a rule for each message type and a specific update size assigned to each type. 
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(INFER (‘Event is new_message’”’) (“InputRight’’) 
(“OutFacts”)) 
) 


d. Right Output Process 


The nght output process takes messages of any class whose status is “output” and 
whose direction is “right” and asserts them on the bus or network to the terminal. It also 
keeps instantiates the necessary loading measurement objects. 

With respect to loading, left input process has kept track of the size of raw 
messages from the host. The left output process keeps track of the size of raw messages 
from the terminal. This process keeps track of the size of messages as they will actually 
be transmitted. 

When an Agent message is decoded, the left output process will kept track of the 
size of messages as received (and, therefore, take credit for the size reduction of Agent 
operations). When messages are encoded, the size of the unencoded versions is recorded 
by the encoding heuristics in the temporary message. Therefore, when it gets instantiated 
as an output message, the size that would have been transmitted is known as well as the 


size actually transmitted. 


(1) — Production Rules 
This knowledge base is called “rightout.” 


IF The status of ANY message is output 
The direction of THAT message is night 
The class of THAT message is interesting 
(The form of THAT message is raw OR 
The message of THAT message is constructed)”” 
THEN FIELD (string of THAT message, position of 
message time, size of message_time) is TIME/”! 
FIELD (right_output_buffer, 1, SIZEOF( THAT message)) 
TRIGGER (right _output_buffer, &pos)” 


°° This message already has a header 

*' Time if a function of message input output, plus processing differential. 

‘2 TRIGGER tells the system that the buffer specified by the argument is ready for insertion on the bus or 
network connection on either side of Agent. The second argument is the size of the message. These 
arguments are notional in that the specific steps and forms will be determined for Agent during detailed 
design for a particular installation. 
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THEN 


(2) 


The status of THAT message is OLD 

LOCK J 

J=J+1 

UNLOCK J 

message[j] 1s_a raw_stream 

rawsize of message[j] is SIZEOF (string of THAT 
message) - header_in 

time of message[j] is message_time of THAT message 


The status of ANY message 1s output 

The direction of THAT message is right 

The class of THAT message 1s interesting 

The form of THAT message is encoded 

FIELD (string of THAT message, position of 
message time, size of message_time) is TIMEf”’ 

FIELD (right_output_buffer, 1, size of THAT message) 

TRIGGER (right _output_buffer, &pos) 

The status of THAT message is OLD 

LOCK J 

J=J+1 

UNLOCK J 

message[j] 1s_a encoded_stream 

rawsize of message[j] is SIZEOF (string of message[m]) - 
header_in 

time of message[j] is message_time of message[m] 

object[&m] is_a encoded_stream 

The exploded_size of message[j]]** is the exploded_size of 

THAT message 


Meta Rules 


(LOOP (FALSE(EVENT (“terminate”))) 


( 
) 


(INFER () (“rightout”) (“OutFacts”)) 


*3 Since this is an encoded message, Agent created it from one or more other formatted messages. Or it 
could be an internal Agent-to-Agent message. In any case, it must be assigned a message time that the 
terminal will consider to be legal. In this example, the current system time is used as the message time. 
During detailed design the timing problems will be fully resolved. 

* The “exploded size” is simply the size of the messages that would have had to have been transmitted 
had Agent not been operating. This value is calculated as the temporary message is constructed, update 
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DELTA COMPONENTS 


There are two processes (minimum) of the delta components—an encoding 
process and a decoding process. They operate asynchronously of each other. There must 
be at least one of each but there can be as many of each as needed to keep up with the 
loading. Thus a platform with no reporting responsibilities within the Surveillance NPG 
may have a single encoder process and as many decoders as are needed to keep up with 
the flow of messages. A node with reporting responsibilities may have additional 
encoders in order to keep up with the encoding load. A multiprocessor environment is 
best for this type of architecture. Figure 22 shows the parts of the architecture discussed 


below. 
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Figure 22, Delta Components and the Shared Component 
The creation of new encoding/decoding components is performed by the load 


analyzer, which has rules to determine the optimal number of components for the current 


Situation. 
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| Encoder 


a. “Simple” Delta Messaging 


The original and simplest form of delta messaging transmits only the fields that 
have changed from the previous update, and transmits them in their original form. Thus, 
if only the position and message time have changed, only these two fields will be 
transmitted. The agent on the receiving side will find the previous message, supply the 
missing fields, and pass it on to the host. 

The complication is that the terminal always sends out three or six word messages 
regardless of how much data is actually put into the message. Therefore updates must be 
“batched” as well, so that each Agent message will be transformed into many regular (or 
“raw’’) update messages on the receiving end. 

If multiple processors are working simultaneously, therefore, they work to build 
the same update message (which is why, as each update is added, the so-called 


“temporary message” is locked). 


(1) Production Rules 
This rule base is called “deltaencode.” 


IF The mode of Agent is simple_delta 
The status of ANY message is entry 
The direction of THAT message 1s left 
THEN LOCK. ONE of THOSE messages” 
The encode-message of THAT message is NAME (THAT 
message)” 
The status of THAT encode_ message is encoding 
UNLOCK THAT message 


IF The track of ANY message is the _same_as the track of 


*> LOCK ONE is a special version of LOCK. Only one of the messages of the set identified in the 
antecedents is locked. Which one is locked is entirely arbitrary. It is assumed that the implementation of 
the semantic network will cause the eldest message marked “entry” to be selected. Just as nested 
specifiers reduce the set referred to by THAT or THOSE, so does LOCK. After LOCK, THAT or THOSE 
refer only to the locked objects—in this case the message we wish to handle. 

*6 NAME is a function that returns the name of the object. The name was given by concatenation when 
the object was first instantiated. Thus subsequent rules can refer to that message by name. 
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$encode_message”’ 

The type of THOSE messages is old 

The message_time of the $encode_message minus the 
message time of ANY of THOSE messages 
is_less_than_or_equal_to the update frequency of 
the $encode_message™ + time_delta® 


THEN The old_encode_message is “empty” ONLY® 
The old_encode_message is the NAME (THAT message) 
ONLY 
IF The old_encode_message is “empty” 
THEN The direction of the $encode_message is right 


The $encode_message is_a output_message 
The status of $encode_message is output 
EXIT 


IF NUMBEROF (temporary_message) is_greater_ than zero 
THEN CONTINUE” 
ELSE LOCK temporary_message 

LOCK e” 

e=et] 

UNLOCK e 

rmessage[e] 1s_a temporary_message 

gpos = | 

FIELD (string of temporary_message,gpos,) is the code 

for™ simple delta 
gpos = gpos + size of simple _delta_code 


IF TRUE 
THEN FIELD (string of temporary_message, gpos,) is “XX’™ 


*” Note that the dollar sign, or evaluation symbol, tells the engine to substitute the contents of 
encode_message in the antecedent before evaluating further. Since the name of a message 1s stored in 
“encode_message,” the name of that message 1s used in the evaluation. 

*® This value is assigned when the semantic network is built as a slot associated with the message type. 
Thus a J3.2 may have one update rate and a J3.3 have another. Therefore new targeted messages are 
assigned to the appropriate type of message rather than, simply, to “message.” 

°° If update times do not form a completely accurate sequence, then perhaps a small delta will be needed 
to make sure that the correct earlier message was located. If no previous update 1s found the message will 
simply be transmitted in raw format. 

* Agent cannot use simple delta encoding on a message for which it has no immediate predecessor. 

*' CONTINUE is a no-op. 

°? Must be global if there are multiple instances of the encoding process operating. 

°? “Of? and “for” mean precisely the same. 

* XX is an arbitrary field code that indicates that what follows is a new message. The format of the 
batched message is in general a field code followed by the field itself. Thus field code 1 means update 
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gpos = gpos + 2 
FIELD (string of temporary_message, gpos,) is “01” 


gpos = gpos + 2 

FIELD (string of temporary_message, gpos, size of type) is 
type of message[e] 

FIELD (string of temporary_message, gpos,) is “02” 

gpos = gpos + 2 

FIELD (string of temporary_message,e) is the track of 
message[e] 


gpos = gpos + size of track 

FIELD (string of temporary_message,e) is the update_time 
of message[e]” 

gpos = gpos + size of update_time 


IF The lat of message[e] is the lat of old_encode 
THEN Continue 
ELSE FIELD (string of temporary_message, gpos, size of lat) is 


the lat of message[e] 
gpos = gpos + size of lat 


IF The lon of message[e] is the lon of old_encode 
THEN Continue 
EESE FIELD (string of temporary_message, , size of lon) is the 


lon of message[e] 
gpos = gpos + size of lon 
The exploded_size of message[e] is the exploded_size of 
message[e] plus the size of update_message 
UNLOCK temporary_message 
EXIT 


b. Meta Rules 


There is only one set of meta rules for the encode delta component(s). This set 1s 


as follows: 


time, which all messages have, field code 2 means track number, and so on. The special code of XX 
means that this is the beginning of a new message, so that the decoding algorithm will start looking for a 
sequence of field codes and fields for the new message. If no known field code is encountered, then the 
message end has been found. Since outgoing messages can be of almost any length, modulo three words, 
Agent keeps adding updates to the temporary word until the exception handler forces it to be output. 

°° The code for simple delta messaging. In the real implementation, “code of type” should be used. It is 
given explicitly here to remind the reader that such codes are arbitrary. 

* All delta messages begin with the trio of type, track, and update_time. The type is needed to know 
what fields to look for, the track is needed to match up with previous tracks, and the update time will 
always be different. Other fields are added only if different from the previous update. 
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(LOOP (FALSE(EVENT (“terminate”))) 


( 
(GETFACTS (“Agent Status”) (Status _facts)) 
(IF (TRUE (“strategy of Agent is simple_delta”)) 
( 
(INFER () (“deltaencode”’) (“OutFacts”)) 
)) 
(IF (TRUE (“strategy of Agent is extrapolation”)) 
( 
(INFER () (“extrapencode”) (“OutFacts”)) 
)) 
) 


Any additional encoding schemes can be added in the same fashion to this meta 


rule base. 


Ie Decoder 
a. Production Rules—Routing Messages 
IF If the status of ANY message is entry 
The direction of THOSE messages is right 
The form of THOSE messages is encoded 
THEN Action is NULL 
ELSE EXIT 
IF The encoding scheme of ANY message is simple_delta 
THEN Action 1s process delta message 
IF The encoding scheme of ANY message 1s extrapolation 
THEN Action is process extrapolation” 


b. Production Rules—decoding delta messages 


The following will decode any number of messages encoded with so-called 
“simple” delta messaging. The name of the base 1s “decodedelta” 


IF If the status of ANY message is entry 
The direction of THOSE messages 1s right 
The form of THOSE messages is encoded 


*” Note that ONLY is not specified in these cases. We are checking to see if messages of either or both 
schemes are ready for decoding. 
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THEN 


ELSE 


THEN 


THEN 


THEN 


THEN 


WHILE 
BEGIN 


THEN 


LOCK _ONE of THOSE messages 

The status of THAT message is decoding 
&Name is NAME (THAT message) ONLY 
EXIT® 


FIELD (string of $&name, &dpos,2) is “XX” 

&pos = &pos + 2 

LOCK m 

m=m+l 

UNLOCK m 

message[m] is_a message 

The type of message[m] is FIELD (string of &$name”, 
&pos, size of message_type) 

&pos = &pos + size of message_type 


The type of message[m] is J3.2 

message[&m] is_a J3.2 

DEINSTANTIATE message[m] FROM message 
&interval is update_interval of J3.2 ONLY 


The type of message[m] is J3.3 

message[&m] is_a J3.3 

DEINSTANTIATE message[m] FROM message 
interval is update_interval of J3.3 ONLY 


The type of message[m] 1s J2.2 

message[&m] is_a J2.2 

DEINSTANTIATE message[&m] FROM message 
&interval is update_interval of J2.2 ONLY 


FIELD (string of $&name, &pos, 2) not_equal_to NULL 
Decoding 


TRUE 

The type of message[m] is FIELD (string of message[&m], 
&pos,2) 

&pos = &pos + 2 

The update_time of message[m] is FIELD (string of 
message[&m], &pos, size of update_time) 

&pos = &pos + size of update_time 


** If a message to process isn’t found that doesn’t mean there was an error. A parallel process could have 
picked up the message for decoding before this process was able to find it. 

°° Evaluation is from right to left. So that first the parser knows that it is a local variable, second, it knows 
to perform substitution on it. 
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THEN 
ELSE 


THEN 


ELSE 


THEN 


ELSE 


THEN 


END 


The track of message[m] is FIELD (string of message[m], 
&pos, size of track) 
&pos = & pos + size of track 


The track of ANY message is the track of message[m] 

The update_time of THAT message is the update_time of 
message[m] - &interval 

#old_message = NAME (THAT message) 

DEINSTANTIATE message[m] 

EXIT” 


FIELD (string of message, &pos,2) is lat_type 

&pos = &pos + 2 

Lat of message[m] 1s FIELD (string of message[m}, &pos 
+ size of lat, size of lat) 

&pos = &pos + size of lat 

Lat of message[m] is lat of #old_message 


FIELD (string of message, &pos,2) is lon_type 

&pos = &pos + 2 

Lat of message[m] is FIELD (string of message[m}, &pos 
+ size of lon, size of lon) 

&pos = &pos + size of lon 

Lat of message[m] is lat of #old_message 


TRUE 

Direction of message[m] 1s left 

Status of message[m} is output 

LOCK J" 

J=J+1 

UNLOCK J 

Message[j] 1s_a raw_stream 

The rawsize of message[j] is size of update 

The time of message[j] 1s the update_time of message[m] 


Decoding 


” This is an error exit, in that the previous update message for this track could not be found. Therefore 
we can only drop the message at this point. 
" We’re going to create an history record for each message decoded. This will be used in calculating the 


effective bandwidth. 
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e Meta Rules 


The following meta rules’ for decoding call knowledge base 
“checking for messages” to determine if there are entry messages from the right that 
need to be decoded, and then calls the knowledge base appropriate for the decoding. Any 
number of knowledge bases can be included here. Only one is actually documented at 
this point (simple delta messaging). 

(LOOP (FALSE(EVENT (“terminate”))) 


( 

(INFER () (checking for _messages) (out_facts)) 

(IF (TRUE (“Action is process delta message”’) 
(out_facts)) 

( : 
(INFER () (“deltadecode”) ()) 

)) 

(IF (TRUE (“Action is process extrapolation”) 
(out_facts)) 

( 
(INFER () (“extrapdecode”) (“OutFacts”)) 

)) 

SHARED COMPONENTS 


This process analyzes net loading and adjusts the strategy of Agent accordingly. 
Every time a message is sent or received a history record is created for that transmission. 
If the message was encoded, the raw message size as well as the encoded message size is 
included. 

The first step is to prune the history records of all information older than one 
frame. The next step is to determine the total number of characters (or bits) that are being 
transmitted within the NPG. If this number is higher than the upper trigger level (which 
is set as a result of laboratory experiments), delta messaging kicks in. When it falls below 
the lower trigger level, delta messaging kicks out. These changes have an effect only on 
encoding. Whenever an encoded message is received it is decoded regardless of the status 


of Agent. 
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As written, Agent kicks in or out based on NPG loading. It is possible to include 
node loading as well, with an appropriate exchange of TIMs and TOMs to determine the 
transmission slots available to the node. This would be compared with its output loading 
to determine if node saturate were either occurring or close to occurring. If so, a 
reduction strategy would be enacted for this node (the others would continue to operate 
according to their information about the NPG and themselves). This could include update 
rate reduction (which would be handled by the left input process, which would simply 
discard updates at some adjustable rate so that the transmit requirements would match the 


transmit capability). 
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V. AGENT METHODS FOR LINK 16 
INTRODUCTION 


For this project, several techniques are under development for reducing 1) the 
length of frequently-transmitted messages and, 2) the frequency of transmissions. These 
techniques are lossless in that there is no concomitant reduction in content or user 
situation understanding. These techniques are under development for initial evaluation 
and demonstration, to be later verified in the NRaD Systems Integration Facility (SIF). In 
the SIF, the primary purpose of establishing key benchmarks is to assist in deciding 
between alternative object-oriented (OO) implementations. Object-oriented technology 
will be employed as much as practicable in this demonstration. Irrespective of 
programming style, benchmarks will establish the best possible methods. Therefore, the 
prototypes may contain a mix of OO and procedural components. The benchmarks will 
reveal, for each technique, the best possible gain in virtual bandwidth. 

Simultaneously, a software agent will be designed to further reduce bandwidth by 
adding intelligent, distributed link control, as well as to enhance the message length- 
reduction strategies with such techniques as transmission frequency reduction. As stated 
earlier, the name for this agent is “Agent.” Software agents have been shown to be 
especially useful for network management in other contexts. The rules of the link will be 
instantiated in Agent, which, along with an automated transmission planning capability, 
can provide substantial gains in virtual bandwidth. 


ATOMIC DATA ELEMENT TRANSMISSION (“DELTA MESSAGES”) 


In this technique, redundant elements of messages (e.g., track update messages) 
will be reduced to a minimum. In general, only the elements of a message that have 
changed since the last update will be transmitted, together with identifying information. 
The goal is to provide a decrease of one-third to two-thirds bandwidth requirements for 


track messages, in addition to only transmitting such Delta Messages when new 
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information deviates outside expected parameters as determined by relative navigation 
models, see Extrapolation-Driven Updates, below. The effective reductions would make 
much needed bandwidth available for other purposes, plus increase the links overall track 
handling capabilities through being able to identify and update a greater number of 
tracks. 

If the OODBMS chosen by other parts of the RTR program becomes the 
bottleneck in the process, message objects with strong real-time requirements will be 
cached in RAM, or other strategies developed, to enable the system to keep up with the 
link requirements. 

Figure 23, Physical Implementation, describes how the smart agent will fit into 
the existing system. Details of the operations of Agent are described in a previous 


section. 
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Figure 23, Physical Implementation 


Figure 24 shows a conceptual view of delta message reduction. Figure 24 shows 
the type of information a delta message may contain. Although the TADIL message type 
is “Free Text,” a message type local to Agent will be within the message, for each type of 
message it transmits. Following the message type is an indicator of the number of fields 
present for that particular message type. After that is a variable number of fields with 


field types (i.e. integer, character, binary, etc.) associated with the message type. 
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Although most fields are fixed-length, some will be variable. For example, with respect 
to latitude, although a full update message has new data, probably only a very few of the 
least significant bits from the previous update have changed. Agent will identify and 
insert the changed bits, and the field length will be the number of them. The receiving 
Agent will know to replace the lower order bits from the previous message with the new 
ones. Of course, if the whole field changes, then the whole field will be sent. It is 
understood that if there is significant change in the original TADIL message, the delta 
message could be significantly longer than the original message. The implication is that 
the delta message is checked agianst the original message size. Only the shorter of the 
two Is sent. 

That this kind of severance system can be introduced has already been proven 
with the Link 16 virtual gateway, which today provides both a passive tap, for relaying 
the tactical picture to other systems, and the ability to insert messages directly. Agent 
will build upon the structure of Galaxy. 





Figure 24, Conceptual Implementation 
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Some types of messages internal to Agent will be control messages not directly 
related to existing message types. 

The many different link messages will be surveyed for their applicability to this 
type of length-reduction technique. 

One challenge is that, at present, track update messages belong to the surveillance 
NPG, which is connected to one of only three existing JTIDS buffers. The buffer is there 
to ensure that all messages of the surveillance type will be transmitted (in overload 
conditions, a message not buffered can be tacitly dropped from the system).The C2P 
manages itself based upon the available buffer size. At present, free-text messages do not 
belong to the surveillance NPG. The poses no problem for the benchmark demonstrations 
because there 1s an operator-assignable buffer that can be used. For the long term, a plan 
will be created for either 1) including the free-text message in the surveillance NPG, 2) 
assigning a buffer to the free-text messages, or 3) simulating buffer operations within 


Agent. 
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From what is known at the time of this writing, the best answer is to have free- 
text messages included in the surveillance NPG, which would cause a small modification 
to the C2P’s buffer size prediction algorithms (JTIDS would look more efficient to the 
C2P than it does today). 


UPDATE BUNDLING 


Not all frequently-transmitted messages are of high priority. Also, the priority of 
a given type of message may vary with the situation. Delta messages, or other types of 
messages, can be bundled into a single transmission using the free-text message format. 
This would make, for example, the transmission of historical track data feasible (by 
encapsulating a full message and all of the subsequent updates into a single free-text 
message). Because all of the information is in a single message, rather than in many 
messages, the system may be able to process the information more efficiently (that is, the 
total package of information 1s received more quickly, and less administrative load on the 
system). 

To minimize this overhead, another function might be to “bundle” a historical 
message with all its subsequent delta messages, so that a platform entering the network 
could be updated on all of the data concerning a particular track in a single, free-form 
transmission of minimal size. 

In today’s system, it is a goal that all track updates be sent within twelve seconds. 
This is true for slowly-moving objects, such as ships, and faster-moving objects, such as 
airplanes. Resources permitting, delta messages from slower-moving objects would be 
“packed” as in figure 4 above, for transmission in a single message after a fixed interval 
(TBD). At the receiving end, all of the updates would be applied with Agent, with the 
resulting full update message being sent on to the C2P. 

It is important to validate bundling as a concept. This means that in the SIF, the 
total network loading of sending multiple small messages must be compared to the 
loading from sending one, larger message. Network performance-measuring tools 


currently being developed by others will be used to measure the expected gain. Since it is 
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estimated that network bookkeeping amounts to some twenty percent of net loading, the 
gain promises to be significant. 

This task will be coordinated with task 4.2.5, Active Network Management, in 
order to implement variable packing. For example, packing parameters can be altered, or 


packing completely eliminated, as the tactical picture changes. 


EXTRAPOLATION-DRIVEN UPDATES 


In this technique, each type of vehicle being tracked is modeled on every 
platform, utilizing a flat Earth 3-D model (dead reckoning). Each platform makes a 
projection of the tracked-vehicle’s position at its next-scheduled update cycle, based on 
observed behavior. If the predicted position is close enough to the actual position, then 
either no transmission is made and the individual Agents generate the update locally, or a 
very small transmission is made confirming that the prediction is accurate. If too great a 
deviation has occurred, then a full update message or a delta message is actually 
transmitted. Since most tracked vehicles behave predictably over short intervals, this 
technique promises to greatly reduce network loading—with no loss of information at the 
receiving platforms. 

At any given time, one platform has the reporting responsibility for a given track 
(based on track quality). The concept of extrapolation-driven updates is to have a set of 
vehicle simulations at each platform that predict the position of the tracked vehicle at the 
next scheduled update. If the prediction of the update matches the reported “true” 
position, within an appropriate tolerance (calculation based upon range and sensor 
resolution), no update would be sent. Instead, Agent would internally generate an update 
message based on its prediction and send that update to the C2P. The concept is 
illustrated in Figure 26. 
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Figure 26 


The shape and size of the error tolerance is determined by the vehicle type, 
elapsed time, and the accuracy of the sighting information. For example, if the gaussian 
circular-error-probable (CEP) of the sighting is known, the circular coverage function 
can be used to determine if the sighting is within a particular level of assurance of a 
circular tolerance shape. See Figure 27. In the process, the total probability distribution 
within the circle is integrated. If, say, a ninety percent assurance is required, then ninety 


percent of the distribution must lie within the circle. If so, no message is sent. The 


oo 





automatic curve fitting mechanism then adjusts to the new position, recalculates the error 
shape, and continues. If not, the actual position is sent and the curve fitting adjusted. 
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A = actual sighting 
P = predicted sighting 


Figure 27, Assurance Calculations 


The problem of predicting a location based on historical track information is non- 
trivial. Agent, for example, will have to know when a sighting is clearly improbable, and 
thus in error, so that it can be tacitly discarded. While for short intervals a linear 
prediction may be useful, for longer intervals a more complex prediction algorithm must 
be employed. One important study to be performed in the out years will be to determine 
the best prediction algorithms to employ. A fixed circle will be used as the error 
tolerance, along with a linear curve fit with zero uncertainty. However, this will by no 


means demonstrate the potential effectiveness of the extrapolation technique. 
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TRADITIONAL COMPRESSION 


If the targeted processor can keep up with the data rate, a loss-less compression 
technique, such as Lempel-Ziv, can be applied to lengthy messages. The messages will 
be examined for good candidates for this type of compression, and estimates of the time 
necessary for the various algorithms to perform the compression will be estimated. When 
resources permit, an attempt to establish a benchmark for this type of compression will 
be made in the SIF. 

With respect to video and voice, at this point it is believed that hardware 
assistance will be required for compression/decompression. This task is therefore limited 
to identifying all of the platform types that can be connected to the link, and determining, 
to the extent information 1s available, 1f COTS compression boards are available for these 


platforms, or will be available within a reasonable time span. 


EXTENSIONS 


The immediate application is to reduce the amount of redundant information 
transmitted over the link (see individual tasks below). However, additional autonomous 
agent functions could help to better manage the tactical links by detecting problems and 
taking steps to alleviate the consequent load on the net, when possible and acceptable. 

The initial analysis and design of the intelligent agent architecture will also be 
directed towards meeting the system requirements for robustness in the face of 
communications gaps or failures. The architecture provides significant opportunity for 
extension. Out year tasks will develop agents that manage other types of messages, 
support recognition, routing and processing of new RTR message types, and call 
attention to messages requiring quick reaction. 

Over the course of this work and subsequent efforts, all message types will be 


examined for ways in which a intelligent agent could optimize network operations. 
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This effort will include interviews of expert users of the system in an effort to 
collect additional cases or functions that are appropriate to intelligent agent action, and 


where appropriate seek to incorporate this in the current network schema. 
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VI. SUMMARY 
A. WORK ACCOMPLISHMENTS 


1. The engineering design of Agent has been documented to the point where 
detailed design can use it as a guide. 

2. All of the software and functional requirements of Agent are satisfied by this 
design. 

3. The Agent engineering design is not specific to Link-16 or any other tactical 
network. 

4. Agent is compatible with a multi-processor implementation, but can run on a 
single-processor machine. | 

5. Agent has its own inference engine, the special features of which are 
described in detail. 

6. Agent is otherwise compatible with IBM’s Agent Building Environment 
(ABE). During detailed design, another took kit can be substituted 1f found to 


be more appropriate. 


B. WORK TO BE DONE IN SUBSEQUENT PHASES 


1. Make sure that the rule bases are thoroughly debugged, especially with 
respect to NPG loading calculations. Construct a test bed in SNOBOL for 
this purpose. 

2. Add rules for calculating node loading. 

A low-level briefing on the engineering design should be written. 

4. The Jow-level briefing should provide the basis for a conference to discuss 
the engineering design among the interested parties. 

5. Add formal BNF to describe the facts and rules. Formalize the otherwise 
informal notations used in this document. 


6. Create rules for passive net normalization. 
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10. 
11. 
1 
is: 
14. 


Se 


Create rules for agent-to-agent “update me” messages for active 
normalization. 

Insert sequence numbers into encoded messages (quasi token ring scheme) so 
that receiving nodes can detect missing updates. 

Agent as written does not compare actual net loading with predicted net 
loading in order to do a kind of “sanity check”’ on its own operations. This 
can be added. 

Encode and Decode rule bases for other heuristics need to be written. 

A high-level briefing on the engineering design should be written. 

A low-level briefing on the engineering design should be written. 

A command-level briefing on Agent should be written. 

At some point before detailed design, a survey of inference engines should be 
made to see if any are close enough to Agent requirements to be used as a 
point of departure. 

At some point before detailed design, a survey of agent-building toolkits 


should be made. 
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Vil. FUTURE WORK 


Today’s Link 16 is passive, for the most part requiring acknowledgments only for 
certain types of messages, such as military orders. However, with Agent in place, and 
Agent-to-Agent communications demonstrated, more complex ways of fine-tuning 
network operation are possible. In an example mentioned above, a platform could request 
complete historical information on a specific track, and receive that information in an 
efficient manner. Also, the frequency of updates could be controlled by the individual 
needs of the receiving platforms, with the platform requiring the most urgency receiving 
priority. Network optimization, while nevertheless working within today’s rules and 
restraints, can be an operational reality. 

In the out years, an attempt will be made to quantify the gain expected from 
allowing the Agents to communicate with each other, whereby they adjust network 
parameters in real time. For an example involving considerable intelligence, update rates 
could be dynamically adjusted by the situational assessment of the importance of a track 
relative to the tactical situation. This is a significant step towards more autonomous 
functionality based on an agent’s own situation assessment. 

Additional, more specialized agents may contain user-specific knowledge. For 
example, Agent could passively notify the special agent of events as they occur, and the 
special agent could provide various types of amplifying information to the console user 
based upon the operator’s needs. The specialized agent may be capable of a range of 
responses, from simple alert messages to action sequences. 

In the case of urgency-driven updates, the receiving platforms would examine the 
current rate at which a given track was being updated, and, if satisfactory, do nothing. If 
a higher rate of update is desirable, a Agent to Agent message is generated that increases 
the update rate. In this way, update rates could be drive up or down based upon the 
perceived tactical situation. A very intelligent and platform-specific Agent could do this 
function transparently. 

Ideally, Agents would utilize a CORBA-compliant object-request broker (ORB), 
such as Iona’s ORBIX, or possibly incorporate the JAVA applet to application 
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architecture, to transparently manage track updates (and, indeed, all message objects). 
Each C2P would, under an ORB, appear to have all track objects present in its own 
address space, regardless of where on the link they actually resided. Then, rather than 
transmit at fixed intervals, platforms could simply examine the track objects at whatever 
frequency is thought to be important. This would reverse the idea of the link—from 


fixed-interval transmission to as-needed query. The ORB would ensure that the data was 


current. Figure 7 shows a layered view of a component-based architecture. 
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Figure 28, Orb-Based Architecture 
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As attractive as the use of an ORB-based system is, the current overhead of an 
ORB constitutes a significant chunk of bandwidth and may, with today’s technology, 
slow down real-time processing, precluding its use in this context. The key to the 
analysis 1s at the system level, not at the link level. 

Beyond the applicability to military communications, such technology has 
obvious implications with respect to commercial communications networks 
(INTERNET, or any other digital communications network). While it is acknowledged 
that the development of an agent architecture is not “the solution”, it has the potential to 
alleviate already crowded communications lines, while not sacrificing accuracy. The 
robustness of such an approach has not yet been adequately determined. However, it is 
felt by the author that such an approach will provide for more optimized network 
utilization of available assets (bandwidth), ultimately resulting more efficient and overall 


faster network operations. 
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APPENDIX 
CONCEPTUAL PROTOTYPE SOURCE CODE 


Note - This prototype was developed utilizing: 


e Intel Pentium 166Mhz processor 

a Windows 95 OS 

e Rogue Software gui builder and TCP/IP 
sockets development packages 

® Borland C++ version 4.51 compiler 


Copyright material (header files included with the above build packages) are 


omitted. 


ypedef void (* ENTRY \ void *); 


lass CService { 
private: 
LPSTR m_ServiceName; 
HANDLE m_ExitEvent; 
SERVICE_STATUS_HANDLE m_ServiceStatusHandle; 
BOOL m_PauseService; 
BOOL m_RunningService; 
HANDLE m_ThreadHandle; 
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ENTRY m_EntryFunction; 


int m_StartTimeOut; 
int m_StopTimeOut; 
int m_PauseTimeOut; 
int m_ResumeTimeOut; 

void OnPauseService(); 

void OnResumeService(); 

void OnStopServiceQ); 

long OnStartService(); 


static VOID ServiceMain(DWORD argc, LPTSTR *argv); 


BOOL SCMStatus (DWORD dwCurrentState,DWORD dwWin32ExitCode, 
DWORD dwServiceSpecificExitCode,DWORD dwCheckPoint, DWORD dwWaitHint); 


static VOID ServiceCtrlHandler (D WORD controlCode); 


VOID Exit(DWORD error); 


/Anstall variables 

DWORD m_dwDesiredAccess; 
DWORD m_dwServiceType; 
DWORD m_dwStartType; 
DWORD m_dwEnrrorControl; 


LPSTR m_szLoadOrderGroup; 
LPDWORD m_IpdwTagID; 
LPSTR m_szDependencies; 


public: 
CServiceQ); 
~CService(); 


//service entry point 
long InitService(LPCSTR name,void * EntryFunction); 


//service timeout settings 

int SetStartTimeOut{int milisec); 
int SetStopTimeOut{int milisec); 
int SetPauseTimeOut({int milisec); 
int SetResumeTimeOutiint milisec); 


//service install / un-install 
int SetInstallOptions(DWORD dwDesiredAccess, DWORD dwServiceType, 
DWORD dwStartType,D WORD dwErrorControl); 
int SetInstallOptions(LPSTR szLoadOrderGroup,LPD WORD IpdwTagID, 
LPSTR szDependencies); 
int InstaliService(LPCSTR szInternName,LPCSTR szDisplayName,LPCSTR szFullPath); 
int InstaliService(LPCSTR szInternName,LPCSTR szDisplayName,LPCSTR szFullPath, 
LPCSTR szAccountName,LPCSTR szPassword); 
int RemoveService(LPCSTR szInternName); 


#include “zapp.hpp” 
#include “mdiapp.hpp" // Main App Class Definitions & Includes 
ZAPP_IMPL_ASSERTS 


// zpb_begin Global Vars 
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HWND status_hWnd; 
char stuff[ LBUFSZ]; 


char *DxBuf[DXBUFSZ]; 
int DxBuflnp; 
int DxBufNdx; 
// 
// SipQ is an object which allows independent execution of member 
// functions. 
Hf 


class SIpQ { 
#define NTASKS 50 
unsigned long SITm[NTASKS]; 
unsigned long WkTm[NTASKS]; 
zMD!ChildFrame *sq(/NTASKS]; 


SipQo; 
~SIpQo; 
unsigned long systime; 
int Slp(zZMDIChildFrame *, unsigned long); 
int CkQQ; 
int Rm(zZMDIChildFrame *); 
}//end SipQ 


public: 


DWORD WINAPI ThreadFunc(LPVOID IpvThreadParm); //forward reference 
SlpQ *pSQ; //pointer to the sleep queue 
// end sleep queue parameters 


// PES TET EFT ES SEFC SS SEER TES ES TS S 


// Track Class Declaration 

// SET EAEKAESESTEEEEEEEEESESEEE 
#define MXTKMS 10000 

#define MXTKPTS 24 

#define HOSTILE AIR 0 

#define HOSTILE_SUB 1 

#define HOSTILE SURFACE 2 
#define UNKNOWN_AIR 3 
#define UNKNOWN_SUB 4 
#define UNKNOWN_SURFACE 5 
#define FRIENDLY _AIR 6 
#define FRIENDLY SUB 7 
#define FRIENDLY_SURFACE 8 


class Trk { 
public: 
TrkQ; 
~TrkQ; 
int upd(); /hrpdate the track info for display purposes 
int dmsg(); /delta message method 
int type; /type of track 
int num; /Arack number 
int xpos; /Icurrent x location for display on track window 
int ypos; “er " # * * 8 # 
int xvec; // x location of track vector endpoint 
int yvec; ios a. 
float altRaw; /t raw altitude value directly converted 
float xRaw; /1 raw coordinate value 
float yRaw; /1 raw coordinate value 
float spRaw,; // raw speed value directly converted 
float xdRaw; // raw delta of coordinate value 
float ydRaw; // raw delta of coordinate value 
zColor clr; //color of display is initially white 
char imSt{ 16); /timestamp is the string directly from the msg 
char typStr[8]; /Itype of track 
char strSn{32]; /funde fined characters 
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char numSt[8]; //track number 

char romSu[LBUFSZ}; //rest of message string 

char OldMsg{[LBUFSZ]; = //Old Message as copied directly out of buffer 
char CurMse{[LBUFSZ]; lINew “ © 8 SS ee 

int OldDel[ LBUFSZ]; //Changed symbols for old message 

int CurDel{[ LBUFSZ]; //Changed symbols for current message 
int MQndx; /findex to the latest entry in MQ 

char *MQ(MXTKMS]; //message buffer for this track 

int cCnt{ MXTKMS]; //symbol count per message, i.e. length 
int dCnt{MXTKMS]; //diff value count between messages 
float csRatio[ MXTKMS]; __//ratio of diff/total count 


WDatAn *AnWn; //Analysis window for Track Txt window 
WTrkTxt *TxWn; //this is a text window for the message buffer 
int distype; //this is a unknown of display bitmap 

char dTypStr[64]; //string for the type of displayed icon 

}v/end Trk 


Hf FESTA SKSSKSSSSSSKKKKKKKAKES 


// Track Queue Class Declaration 

Hf STSEKKCSSKSKKEKCKESCKLKEKEKTKESE 

#define MAXTRKS 400 /{Maximum number of tracks per Q 
class TrkQ { 


public: 


Trk *TQ[MAXTRKS]; //Array of Pointers to Tracks 

Trk *newTrk; /freserve track 

int nTrks; //number of tracks in the queue 

int DTindx; /findex for the track information dialog 

int new TrkTxt; /findex for text message display for tracks 
int xd TrkTxt; //x offset for new TrkTxt window 

int ydTrkTxt; //y offset for new TrkTxt window 

int newTrkAn; /findex for the track analysis window 
TrkQOQ; 

~TrkQO; 

int upd(char *); 

float minlg; /Ahis is for display coordinates 
float maxlg; 

float dellg; 

float minit; 

float maxlt; 

float dellt; 

int rmv(zString *); /removes the track in the message string 
int rescale(); //resets the display coordinates 


//Trk *pcetrk; //global (common) ptr to a current DTInfo Trk 
}J/end TrkQ 


/f FFSSSSSSSSSESSASTSESEREEE SSE 


// Code Book Class Declaration 

// SESKKTKKK SSK KKKKLLEKEKEKEKEKS 
#define MAXFMTS 32 

#define MAXFLDS 32 

class CdBk { 


public: 


CdBkQ; 

~CdBkOQ; 

int fmt{MAXFMTS]}; 
zSting *flds[MAXFLDS]; 


}//end CdBk Class Declaration 


I SSTSSKKSESKKSKKSKREKKKKLSE KEES 


// Track Methods 


i SSCSSSSKAEKSEKKEKEKKKSEESEE EE 


Trk::Trk(){ 


type = 0; /Itype of track 
num = 0; //Atrack number 
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xpos = 0; //current x location for display on track win 


ypos = 0; // rt y rt ti) nr "9 ot + 
clr = WHITE; /Icolor of display is initially white 
distype = UNKNOWN_SURFACE; /Antialized of bitmap is unknowtype 


strcpy(dTypStr,"Unknown Surface"); //string for the type of icon displayed 
strcpy( timStr,""); /imestamp is the string directly from the msg 
strepy( typStr,""); /itype of track 


strcpy( strStr,""); /fandefined characters 
strcpy( numStr,""); /ftrack number 
strepy( romStr,""); //rest of message string 


strepy( OldMsg,""); /{Q\d Message as copied directly out of buffer 
strepy( CurMsg,""); //(New tJ bi " ba] eo tt 


MQndx = 0; /findex to the latest entry in MQ 

int ndx; //emp index for for-loop 

for(ndx=0;ndx<MXTKMS;ndx++) { 

MQ(ndx} = NULL; //message buffer for this track 

}//endfor 

TxWn = NULL; /Kthe text display window is initially NULL 
}//end Trk constructor 
Trk::~TrkQ { 
}//end Trk destructor 


int Trk::updQ){ //update the particular track 
return 0; 
}//end Trk update 


int Trk::dmsg() { 
/Nocal constants 
#define N_TKMSGS 24 // total number of messages 


/Aocal variables 

int tmp_ndx; /Aemporary index 

int lbufNdx; 

/Ant r_curr = MQndx; //actual index into the buffer of messages 


char *ptc]; 
char *ptc0; 
char *ptcm 1; 
int numchrs; 
int ndx; 
int dsum; 
int scnt{ LBUFSZ}; 
char netbuf[LBUFSZ}; 


if(MQndx>2) { /Awe need three messages for delta messaging 
ptcl =MQ[MQndx-1]; //get pointer to message 
ptcO = MQ[MQndx-2}; 
numchrs = strien(ptc 1); 
dsum =0; 
int cent; 
for(ccnt=0;(ccnt<numchrs)&&(ccnt<LBUFSZ);ccnt++) { 
if((*ptc1) != (*ptcO)){ 
scnt{cent}] = 1; 
CurDel[ccnt] = 1; 
dsum++; //this counts number of chars not same 
Jelse { 
scnt{[ccnt] =0; 
CurDel[ccnt] = 0; 
}//endif 
ptcl++; 
ptc0++; 
}//endfor 


ptcO = MQ(MQndx-2]; //reset pointer to line buffers 
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ptcml = MQ[MQndx-3]; 
for(ccnt=0;(ccnt<numchrs)&&(ccnt<LBUFSZ);ccnt++) { 
if((* ptc0) != (*ptcm!)){ 
OldDel[cent] = 1; 
Jelse { 
OldDel[{ cent] = 0; 
}//endif 
ptc0++; 
ptemi++; 
}//endfor 


//following section of code is an initial preliminary coding 

//for run length encoded "delta messages” 

//mote that the major problem for this is that the overhead 

//greatly reduces the number of symbols saved. 
/fran-length encoding is currently turned off. 

#define MXCHGS 10 

#define MXRN_ 16 

int dmsg[ MXCHGS)]; // = {0,0,0,0,0,0,0,0,0,0} ; 

int dmsgndx = 0; // test to see if we have a delta message 

int tmdel = strlen(timStr) + 1; 


int oldcent; 
for(ccnt=tmdel; i 
((cent<numchrs)&&(ccnt<LBUFSZ)); 
ccnt++ yf 
if( ( CurDel[ccnt] = 1 ) //we have a new char 
&&( OldDel[ccnt] == 0 )) { //no delta message 
oldccnt = dmsg{[dmsgndx]; 
dmsg{dmsgndx] = cent; 
if(dmsgndx<MXCHGS){ 
dmsgndx++; 
}//endif 
}//endif 
}//endfor 
ptcl =MQ[MQndx-1]; //reset pointer to curr buffer 
ptcl += tmdel; 
if{dmsgndx <= 0){ /Ave have a delta message 
int ntbfndx = 0; 
int tndx; 
for(tndx=0;tndx<dmsgndx;tndx++) { 
netbuf[ntbfndx]= (*(ptc!+dmsg[tndx])); 
ntbfndx++; 
}//endfor 
netbuf[ntbfndx] = '!'; 
ntbfndx++; 
for(ccnt=tmdel; 
(ccnt<numchrs)&&(ccnt<LBUFSZ); 
cent++ yf 


if{ OldDel[cent] == 1 ){ //delta char 
netbuf[{ntbfndx] = *ptcl; 
ntbfndx++; 
}//endif 
ptci++; 
}//endfor 
netbuf[ntbfndx] = ‘\0'; 


/the following for loops are here because extraneous characters 

//were in the resultant string if the strxxx( routines are used 

/also, if stmcpy() is used instead of strcpy(), very strange 
/Nooking oversized strings were created. ??? library or compiler 77? 

char dmbuf[LBUFSZ] =" 6 

//strcpy(dmbuf,timStr); 

int tmpndx; 

for(tmpndx=0;tmpndx<! 2;tmpndx++) { 
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(*(dmbuf+tmpndx)) = (*(timSm+tmpndx)); 
}//endfor 
Mstrcat(dmbuf,numSt); 
for(tmpndx=0;tmpndx<3;tmpndx++) { 
(*(dmbuf+12+tmpndx)) = (*(numStr+tmpndx)); 
}//endfor 
//strcat(dmbuf,netbuf); 
for(tmpndx=0;tmpndx<=ntbfndx;tmpndx++) { 
(*(dmbuf+ 15+tmpndx)) = (*(netbuf+tmpndx)); 
}//endfor 


//the following sends a track update message to the other machine 

C_WSClient client; = //create the object RTRclient 

if (client.Connect(79,"128.49.133.12") != WSC_SUCCESS) 
MessageBox(NULL,"Connection Fail"," ".MB_OK); 

endif 

client.Send(dmbuf); 

client.Send("\r\n"); 

client.CloseConnection(); 


} else { //send raw message 


//the following sends a track update message to the other machine 

C_WSClient client; —_//create the object RTRclient 

if (client.Connect(79,"128.49.133.12") != WSC_SUCCESS) 
MessageBox(NULL,"Connection Fail"," ",MB_ OK); 

endif 

/stemcpy(netbuf, MQ[MQndx-1]},90); 

client.Send(MQ[MQndx-1 }); //netbuf); 

client.Send("\r\n"); 

client.CloseConnection(); 


} /endif 
jelse{ //first two messages pass through 


/Ahe following sends a track update message to the other machine 

C_WSClient client; //create the object RTRclient 

if (client. Connect{79,"128.49.133.12") != WSC_SUCCESS) 

MessageBox(NULL,"Connection Fail"," "\MB_OK); 

/fendif 

//sumcpy(netbuf, MQ[MQndx-1],90); 

client.Send(MQ[MQndx- 1 ]); //netbuf); 

client.Send("\rin"); 

client.CloseConnection(); 


}//endif 


return 1; 


“TrkQ::Trk QO { 


int ndx; 

for(ndx=0:ndx<MAXTRKS:ndx++){ /fnitialize the track array 
TQ[ndxJ=NULL; 

}//endfor 

new Trk = new Trk; 

nTrks =0; 

minit = 19.0; 

maxit = 23.0; 

minlg = -162.0; //this is for op area field of view 

maxlg = -158.0; 

dellt = maxit - minlt; 
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dellg = maxlg - minlg; 
newTrkTxt =0; //default for null number of TrkTxt windows 
xdTrkTxt =0; //initialize to no delta for TrkTxt windows 
ydTrkTxt =0; 

}//end TrkQ constructor 


TrkQ::~TrkQQ { 
int ndx; 
for(ndx=0;ndx<MAXTRKS;ndx++){ //delete the track array 
if(TQ[ndx]!=NULL) {delete TQ[ndx];} 
}//endfor 
nIrks = 0; 
}//end TrkQ destructor 


int TrkQ::upd(char *pTstr) { 


if( (*(pTstr + 16))=='2'){  //verify valid message type 
stmcpy(newIrk->typSt,pTstr + 15, 4); //type of track 
strncpy(newTrk->numSt,pTstr + 40, 3); //Arack number 
int tmpnum; 
tmpnum = atoi(newTrk->numStr); 
int ndx = 0; 
while( (ndx < MAXTRKS ) //search for existing track 7 
&&(TQ[ndx] !=NULL )){ 
if(T Q[ndx]->num == tmpnum) {break;}//endif this track exists 
ndx++; //note problem with testing NULL ptr 
}//endwhile 


if(TQ[ndx] = NULL){ 
TQ[ndx] =newTrk; //we are adding a new track 

TQ[ndx]->num = tmpnum; 

nT rks++; //need to add error handling for case of MAXTRKS 
newTrk = new Trk; 

Jelse{ 

strcpy(T Q[ndx]->OldMsg, TQ[ndx]->CurMsg); 

}//endif 


stmcpy(TQ[ndx]->timSt,pTstr , 12); //Aimestamp of track message 
/strcat{(TQ[ndx]->tmStr,"\0"); //end-of-string, 
strncpy(TQ[ndx]->typStr,pTstr + 15, 4); //type of track 
stmcpy(TQ[ndx]->strStr,pTstr + 21, 8); /Aundefined characters 
strncpy(TQ[ndx]->numSt,pTstr + 40, 3); //track number 
strepy( TQ[ndx]->romSt,pTstr+ 43); = //rest of message string 
char tmpsu[64]; 

if{stremp(TQ[ndx]->typStr,"02.2"}==0) { 
strncpy( tmpstr, pTstr + 50, 10); 
TQ[ndx]->altRaw = atofi{tmpstr); 

} else { 
TQ[ndx]->altRaw = 0.0; 

}//endif 

float tnpx = TQ[ndx]->xRaw,; 

float tmpy = TQ[ndx]->yRaw, 

strncpy( tmpstr, pT str + 62, 7); 

TQ[ndx]->xRaw = atof(tmpstr); 

TQ[ndx]->xdRaw = TQ[ndx]->xRaw - tmpx; 

strncpy( tmpstr, pTstr + 70, 9); 

TQ([ndx]->yRaw = atofitmpst); 

TQ[ndx]->ydRaw = TQ[ndx]->yRaw - tmpy; 

strncpy( tmpstr, pTstr + 80, 9); 

TQ[ndx]->spRaw = atof{ tmpstr); 
strcpy(TQ[ndx]->CurMsg,pTstr); 

if(T Q[ndx]->MQndx<MXTKMS) { 
TQ[ndx]->MQ{TQ[ndx]->MQndx] = pTstr; 
TQ[ndx]->MQndx++; 

}//endif 


TQ[ndx]->dmsg(); //send the message via delta messaging 
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else 


/tthe following sends a track update message to the other machine 
C_WSChient client,  //create the object RTRclient 
if (client.Connect(79,"128.49.133.12") != WSC_SUCCESS) 
MessageBox(NULL,"Connection Fail",” ",MB_OK); 

/endif 
client.Send(pTstr); 
client.Send("\r\n"); 
client.CloseConnection(Q); 

} //endif 

return Q; 

}//end TrkQ update 


int TrkQ::rescale() { 
if{ nTrks > 1){ 

minlt=TQ[0]->xRaw; 

maxit=TQ[0]->xRaw; 

minlg=TQ[0]->yRaw; 

maxlg=TQ[0]->yRaw; 

int ndx00; 

for(ndx00=0;ndx00<nTrks;ndx00++) { 
if(minit > TQ[ndx00]->xRaw) {minlt=TQ[ndx00]->xRaw; }//endif 
if(maxlt < TQ[ndx00]->xRaw) {maxlt=TQ[ndx00]->xRaw;}//endif 
if(minig > TQ[ndx00]->y Raw) {minlg=TQ[ndx00]->yRaw;}//endif 
if(maxlg < TQ[ndx00]->y Raw) {maxlg=TQ[ndx00]->yRaw;} //endif 

}//endfor 

dellt = maxit - minit; 

dellg = maxlg - minlg; 

#define SCFAC 0.5 

if(dellt > 0.0){ 
minit = (SCFAC * dellt); 
maxit += (SCFAC * dellt); 

} else { 
minit = (SCFAC * minit); 
maxlt += (SCFAC * maxit); 

}//endif 

if(dellg > 0.0) { 
minig -= (SCFAC * dellg); 
maxlg += (SCFAC * dellg); 

| } else { 

minlg -= (SCFAC * minlg); 
maxlg += (SCFAC * maxlg); 

}//endif 

dellt = maxit - minlt; 

dellg = maxlg - minlg; 

}//endif 


return 0; 
}/end rescaleQ) 


‘TrkQ *pTQ; //pointer to the track queue 


| 
i! zpb_end 


// ToolBar Member Functions - MainTools 

thMainMainTools::tbMainMainTools(zMDIMarginFrame *w, zSizer *sz, zBitmap *bmp) 
: ZToolbar(w, sz) { 
theBmp = bmp; 
(ZNEW zToolButton(this, ZNEW zSizer(zPoint{] 1,2), zZDimension(24,22)), 
0, IDM_HELPCONTENTS, theBmp, zRect{112, 0, 128, 15))) 
->show(); 
(ZNEW zToolButton(this, ZNEW zSizer(zPoint(48,2), zDimension(24,22)), 
0, IDM_RTRDXTEXT, theBmp, zRect(0, 0, 16, 15))) 
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} 


->show(); 
// zpb_begin toMainMainToolsConstructor 
// zpb_end 


tbMainMainTools::~tbMainMainTools() { 


} 


Hf 


// zpb_begin tbMainMainToolsDestructor 
// zpb_end 

if (theBmp) 

delete theBmp; 


// Frame Member Functions - Main 


Hf 


// Window Constructor 
WMain:: WMain(const char *title) 
: ZMDIAppFrame(0,ZNEW zSizer(),zSTDFRAME, 


title, ZNEW zMenu(zResId((IDM_MDIWindowMenu))) { 

int MDI WindowPos = 1; 

// zpb_begin WMainConstructor2 

// zpb_end 

menu(ZNEW zMenu(this, zResId(IDM_MainMnMenu))); 

if (MDI WindowPos >= 0) 

menu()->insertDropDown(MDImenu(Q), zString(zResId(IDS_MDIWINDOWMENU)), MDI WindowPos); 

else 

menu()->appendDropDown(MDimenu(, zString(zResId(IDS_MDIWINDOWMENLV))); 
menu()->setCommand(this, (CommandProc)& WMain::cmdMDI Window, IDM_CASCADE, IDM_ARRANGEICONS); 
menu()->setCommand(this, (CommandProc)& WMain::cmdRTRDxDel, IDM_RTRDXDEL); 
menu()->setCommand(this, (CommandProc)& WMain::cmdRTRDxText, IDM_RTRDXTEXT), 
menu()->setCommand(this, (CommandProc)& WMain::cmdRTRDxSym, IDM_RTRDXSYM); 
menu()->setCommand(this, (CommandProc)& WMain::cmdRTRDxTrck, IDM_RTRDXTRCK); 
menu()->setCommand(this, (CommandProc)& WMain::cmdHelpContents, IDM_HELPCONTENTS); 
menu()->setCommand(this, (CommandProc)& WMain::cmdHelpAbout, IDM_HELPABOUT); 

// Create Tool Bar Margin Frame 

zMDIMarginFrame *ToolFrame = ZNEW zMDIMarginFrame( this, 

ZNEW zGrowToFitSizer(ZGRAV_TOP, sizer())); 

ToolFrame->show(Q); 

pIB = ZNEW tbMainMainTools(ToolFrame, ZNEW zGravSizer(ZGRAV_TOP, 30, ToolFrame->sizer()), ZNEW 
zBitmap(zResId(IDB_MainMainTools))); 

p!B->show(Q; 

zMDIMarginFrame *sf=ZNEW zMDIMarginFrame(this,ZNEW zGrowToFitSizer(ZGRAV_BOTTOM,ssizer()):; 
zStatusLineEZ* pSB = ZNEW ZStatusLineEZ(sf, ZNEW zGravSizer(ZGRAV_BOTTOM,), sf->sizer()), ZSL_STANDARDITEM); 
sf->show(); 

pSB->showQ; 

ZNEW Wijtidssid((zMDIAppFrame*)zAppGetA pp Var(app)->root Window(, zString(zResId(IDS_JTIDSSLD))); 
/1 zpb_begin WMainConstructor! 

/! zpb_end 

/! zpb_begin WMainConstructor 


pSQ= new SIpQ; //creates the sleep queue for periodic execution of 
| /fmember functions. 


pTQ = new TrkQ; //creates the track queue for this window 


int x = 0; 

DWORD dwResult = 0; 
DWORD dwThreadld; 
HANDLE hThread; 


hThread = CreateThread(NULL, 0, ThreadFunc, (LPVOID) &x, 
0, &dwThreadid); 
SetThreadPriority(hThread, THREAD _PRIORITY_ABOVE_NORMAL); 


// zpb_end 
show(S W_MAXIMIZE); 
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} 


WMain::~WMain() { 


} 


MH 


// zpb_begin WMainDestructor] 
// zpb_end 


// Menu Item Selection Handlers 


Hf 


int WMain::cmdMDIWindow(zCommandEvt* ev) { 


} 


// zpb_begin WMainMDICmds 
switch (ev->cmd() { 
case IDM_CASCADE: 
cascade(); 
break; 
case IDM_TILE: 
tile(); 
break; 
case IDM_ARRANGEICONS: 
arrangelcons(); 
break; 
} 
// zpb_end 
return 0; 


int WMain::cmdRTRDxDel(zCommandEvt* ev) { 


} 


ZNEW WDelWin((zMDIAppFrame*)zAppGetAppVar(app)->root Window(), zString(zResId(IDS_DELWIN))); 
/! zapb_begin WMainRTRDxDel 

/! zpb_end 

return 0; 


int WMain::cmdRTRDxText(zCommandEvt* ev) { 


} 


ZNEW WDxWin((zMDIAppFrame* )zAppGetApp Var(app)->root Window(), zString(zResId(IDS_DXWIN))); 
// zpb_begin WMainRTRDxText 

// zpb_end 

return 0; 


int WMain::cmdRTRDxSym(zCommandEvt* ev) { 


} 


ZNEW WSym Win((zMDIAppFrame*)zAppGetAppVar(app)->root Window(), zString(zResId(IDS_SYMWIN))); 
// zpb_begin WMainRTRDxSym 

// zpb_end 

return 0; 


int WMain::cmdRTRDxTrck(zCommandEvt* ev) { 


} 


ZNEW WTrk Win((zMDIAppFrame* )zAppGetAppVar(app)->rootWindow(), zString(zResId(IDS_TRK WIN))); 
/1 zpb_begin WMainRTRDxTrcek 

/! zpb_end 

return 0; 


int WMain::cmdHelpContents(zCommandEvt* ev) { 


} 


// zpb_begin WMaincmdHelpContents 
/! zpb_end 
return 0; 


int WMain::cmdHelpA bout(zCommandEvt* ev) { 


DAbout* p=ZNEW DAbout(this, zZResId(IDD_About)); 
p->modal(); 

if (p->completed()) { 

// zpb_begin WMainHelpAbout 

/! zpb_end 
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} else { 

/1 zpb_begin WMainHelpAboutCancel 
// zpb_end 

} 

delete p; 

return 0; 


} 


// zpb_begin WMainMemberF unctions 
// zpb_end 


/{ Pane Member Functions - Dx WinDxTxtPane 
Dx WinDxTxtPane::Dx WinDxTxtPane(zWindow *w, zSizer *sz) : zPane(w, sz, WS_CHILD) { 


// zpb_begin pDx WinDxTxtPaneConstructor! 
// zpb_end 
show(); 

} 


int Dx WinDxTxtPane::size(zSizeEvt *ev) { 
setDurty(); 
/! zpb_begin Dx WinDxTxtPaneSize 
// zpb_end 
retum zWindow::size(ev); 


} 


int DxWinDxTxtPane::draw(zDrawEvt* ev) { 
canvas()->lock(); 
/f zpb_begin DxTxtPaneDraw 
/Aocal constants 


#define N_DXMSGS 18 // total number of messages displayed on the pane 

#define x_head 3 /! x coordinate for the header row 

#define y_head 10 // y coordinate for the header row 

#define x_mbase3  // x coordinate for base (first row) of display messages 

#define y_mbase10 // y coordinate for base (first row) of display messages 
#definem_smt 0 // starting message number 


#define r_offset 15 //offset for spacing between rows 


/Nocal variables 

int tmp_ndx; /hemporary index 

int IbufNdx; : 

int r_ndx; /Irow index for looping through the active messages currently displayed 
int r_Curr,; //actual index into the buffer of messages 


char *msg_curr[{N_DXMSGS]; 


/Iset up the display parameters 
canvas()->pushF ont(new zFont("Helv",zPrPoint{ 12,25,canvas()),900,ffDontCare)); 


/Iclear the window pane 

zRect DxTxtArea; 

canvas{)->getVisible(DxTxtArea); 
/icanvas()->pushPen(new zPen(zColor(GREEN), Solid, 5)); 
canvas()}->pushBrush(new zBrush(zColor(255,128,128))); 
canvas()->rectangle(DxTxtArea); 

delete canvas()->popPen(); 

delete canvas()->popBrush(); 


//set up the display parameters 

// — select a newly created font 
canvas({)->backColor(GRAY); 
canvas()->setTextBackMode(ZTEXT_TRANSPARENT); 
r_ndx= DxBufNdx; 


for(tmp_ndx=0;tmp_ndx<N_DXMSGS;tmp_ndx++) /Aoop through the number of 
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{ /Mines displayed in the window 
r_curr = r_ndx-tmp_ndx; //from most current to past 
if( (r_curr <= DxBuflnp) 

&&(r_curr >=0 »){ 

msg_curr{tmp_ndx] = DxBuf[r_curr]; 
else { 
msg_curr{tmp_ndx] = NULL; 

VW/endif 

‘//endfor 


for(tmp_ndx=0;tmp_ndx<N_DXMSGS;tmp_ndx++) //oop through the number of 
/Nines displayed in the window 
// the following outputs a message to the DXFile window 
if(msg_curr[tmp_ndx}!=NULL) 


canvas()->text(x_mbase, 
(y_mbase+(tmp_ndx*r_offset)), 
msg_curr[tmp_ndx)); 
}//endif 
}//endfor 


delete canvas()->popF ont(); 
/! zpb_end 
canvas()->unlockQ; 

return 1; 


HM 

// Frame Member Functions - Dx Win 

I 

/f Window Constructor 

WDx Win::WDx Win(zMDIAppFrame *w, const char *title) 

: ZMDIChildFrame(w,ZNEW ZzSizer(zDialogUnit(0,0), 
zDialog Unit(310,130)),WS_CHILD|WS_THICKFRAME]WS_SYSMENU|WS_MINIMIZEBOX]|WS_CAPTION, title) { 
/! zpb_begin WDx WinConstructor2 
drwRt=1000L; 
drwTm=0L; 
msgRt=255L; 
msgIm=0L; 
#define DXSR 8L // this object wakes up at the fastest message freq. 


/! zpb_end 

deleteOnClose(TRUE); 

backgroundColor{zColor(255,128,128)); 

menu(ZNEW zMenu(this, zResId(IDM_DxWinDxMenu))); 

menu()->setCommand(this, (CommandProc)& WDx Win::cmdControlRefresh, IDM_CONTROLREFRESH); 
menu()->setCommand(this, (CommandProc)& WDx Win::cmdControlMsgRate, IDM_CONTROLMSGRATE); 
pDxTxtPane = ZNEW Dx WinDxTxtPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizer())); 
pDxTxtPane->show(); 

sizer()->update(); 

/! zpb_begin WDx WinConstructor] OpenDlg 

char *types[6]; 

types[0] = “All Files (*.*)", types[1] = "*.*"; 

types[2] = "Text Files (*.txt)", types[3] = "* txt"; 

types[4] = types[5] = 0; 


zFileOpenForm *p = ZNEW zFileOpenF orm(this,"Open File”, 0, types); 
if (p->completedQ)) { 
/! Use p->name() to retrieve filename 
char * fname; 
char *line; 
fstream fin; 
fname = p->name({); 
fin.open(fname,ios::in); 
| DxBuflnp=0; 
line = new char[{LBUFSZ+1]}; 


_——— 
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fin.getline(line, LBUFSZ); 
while( ( (line[2] !=":') 
||(ine[5] !="-') 
|[(line[8} !=".") ) 
&&(DxBuflnp < 20 )){ 
fin.getline(line, LBUFSZ); 
DxBuflnpt+; 
}//endwhile 
DxBuflnp=0; 
DxBuf[DxBuflnp] = line; 
DxBufinp++; 
line = new char{ LBUFSZ+1}; 
char tbuf[64]; 
while( (fin.getline(line, LBUFSZ)  ) 
&&(DxBuflnp < DXBUFSZ )){ 
//strncpy(tbuf,line + 15, 4); //type of track 
/Ant tbufndx; 
//for(tbufndx=0;tbufndx<4;tbufndx++) { 
/ tbuf[tbufndx] = (*(line+15)); 
//}//endfor 
if((*(line+16)) = '2'){  //verify valid message type 
DxBuf[DxBuflnp] = line; 
DxBuflnp++; 
line = new char{[LBUFSZ+1]; 
}//endif 
}//endwhile 
fin.close(); 
DxBufNdx=0; //Set buffer index to beginning of buffer 
} 
delete p; 
//zpb_end 


// zpb_begin WDx WinConstructor] 


// this block of code finds a previous message that is "closest” to 

// the current message. The index of this message is saved. Note that 

// the previous message has an index to a previous message that it 

// was closest to. Those two messages will be used to generate a 

// "delta message” format. This block of code links the messages 

// before the demo starts. After the algorithm is tested and verified 

// the code will be moved to the location where it will run in realtime. 

// int tmpndx; 

// #define CCMAX 20 = // compare last CCMAX messages from current 
// for(tmpndx=CCMAX;tmpndx<DxBuflinp;tmpndx++) {//start comparing after CCMAX 
// char *Inptr = DxBuf[tmpndx]; _—//current line pointer 

// int Insz = strlen(Inptr); //size of current line 


// wt ccondx; /Andex into the messages 

// for(eendx=CCMAX;ccndx>0;ccndx—){ /Aast CCMAX messages to be compared 

HI char *strptr = DxBuf[tmpndx-CCMAX)]; //previous message 
i] int strsz =strlen(strptr); //size of previous message 

/ int strmin; //min message length 

Hf if(insz<strsz) { 

// strmin=insz; //current line is shortest 

Hf } else { 

I strmin=strsz; //previous line is shortest 

HI }//endif 

/ int strdel = abs(Insz - strsz);__ //diff is counted as diff chars 
// int slndx; 

// for(slndx=0;slndx<strmin;slndx++) { //compare char for char 
/ if{ (*strptr) '=(*Ilnptr) ){ /Af diff then inc delta 

// strdel++; 

/ } //endif 

// strpirt++; /Anc char location in each str 

// Inptr++; 

I }//endfor 

/ }/endfor 


H s/endfor 
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} 


// zpb_end 
// zpb_begin WDx WinConstructor 


//Create the track display for this message stream 
ZNEW WIrkWin((zMDIAppFrame* )zAppGetAppVar(app)->root Window(), zString(zResId(IDS_TRK WIN))); 
pSQ->Sip(this, DXSR); //wake window every x ticks 


// zpb_end 
show(Q); 
} 


WDx Win::~WDx WinQ { 
// zpb_begin WDx WinDestructor! 
pSQ->Rm(this); //Remove this window from the sleep queue 
/! zpb_end 

} 


If 
// Menu Item Selection Handlers 
i 


int WDx Win::cmdControlRefresh(zCommandEvt* ev) { 
DMsgRfsh* p=ZNEW DMsgRfsh(this, zResId(IDD_MsgRfsh)); 
p->modal(); 
if (p->completed()) { 
// zpb_begin WDx WinControlRefresh 
drwRt = (unsigned long) atol(p->_DRtr); 
/! zpb_end 
} else { 
// zpb_begin WDxWinControlRefreshCancel 
// zpb_end 
} 
delete p; 
return 0; 

} 


int WDx Win::cmdControlMsgRate(zCommandEvt* ev) { 
DMsgRate* p=ZNEW DMsgRate(this, zResid(IDD_MsgRate)); 
p->modal(); 


| if (p->completed()) { 


/! zpb_begin WDx WinControlMsgRate 
msgRt = (unsigned long) atol(p->_Mrt); 
// zpb_end 
} else { 
// zpb_begin WDx WinControlMsgRateCancel 
/! zpb_end 
} 
delete p; 
return 0; 


 zpb_begin WDx WinMemberF unctions 


ant WDx Win::wake() { 
zDrawEvt *tmpEv; 
if(pSQ->systime >= drwTm){ 
if(pTQ != NULL){ 
if(pTQ->TQ != NULL) { 
int updndx; 
for(updndx=0;updndx<pTQ->nTrks;updndx++){ //Refresh txt window 
if(pTQ->TQ[updndx]->Tx Wn != NULL){ 
p1Q->TQ[updndx]}->Tx Wn->rtirdrwQ); 
\//endif 
if(pTQ->TQ[updndx]}->AnWn != NULL){ 
pTQ->TQ[updndx}->AnWn->rtrdrw(); 
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iendif 
} endfor 
}/endif 
endif 
pDxTxtPane->draw(tmpEv); 
drwTm = pSQ->systime + drwRt; 
} endif 
if(pSQ->systime >= msgTm){ 
DxBufNdx++; 
if(DxBufNdx>=DxBuflnp){ //not end of buffer, i.e. index less than inputs 
DxBufNdx = 0; /Noop back to beginning of message buffer 
Viendif 


pTQ->upd((char *)DxBuf[DxBufNdx]); //update the track display queue 
//with the new message 
msgTm = pSQ->systime + msgRt; 


}//endif 
retum 0; 
} 
H 
Mf Sleep Queue Member Functions 
// 
// constructor 
SipQ::SipQQ { 
systime = GetCurrentTime(); 
int ndx; 
for(ndx=0;ndx<NTASKS;ndx++) { 
sq[ndx] =NULL; 
S!Tm[ndx]=0; 
}//endfor ndx 
}//end SIpQO 
I 
// destructor 
SlpQ::~S1pQ0 { 
}//end ~SipQO 


if 
/! Periodic Execution Every Specified Number of Ticks 
int SIpQ::Slp(zMDIChildFrame * wptr, unsigned long tcks) { 


int ndx; 
for(ndx=0;ndx<NTASKS;ndx++) { 
if{ (sq[ndx] == NULL )){ 
sq[ndx] =wpt,; 
S!Tm[ndx]=tcks; 
WkTm([ndx]=systime+tcks; 
return 0; 
} //endif 
}//endfor ndx 
return 0; 
}//end SlpO 
If 
I Check the Sleep Queue for Any Member Functions 
int SIpQ::CkQO { 
sysume = GetCurrentTime(); 
int sndx; 


for(sndx=0;sndx<NTASKS;sndx++) { 
if{ (sq[sndx] !'=NULL ) 
&&(WkTm[sndx] <= systime)){ 
WkTm[sndx]=systime+S!Tm[sndx]; 


sq[sndx]->wake(); 
return 0; 
s/endif 
}//endfor ndx 
return 0; 


}//end CkQ0 
Mf 
// Remove window from the queue 
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int SlpQ::Rm(zMDIChildFrame * wptr) { 


int ndx; 
for(ndx=0;ndx<NTASKS;ndx++) { 
if( (sq{ndx] == wptr)){ 
sq{ndx] =NULL; 
Sl1Tm{ndx]=0; 
WkTm{ndx]=0; 
return 0; 
}//endif 
}//endfor ndx 
return 0; 
}//end RmQ 
Mt 
H End Sleep Queue Member Functions 
i 
| 
Hf The Following is a Single Thread Used for Application Multitasking 


DWORD WINAPI ThreadFunc(LPVOID lIpvThreadParm){ 
DWORD dwResult = 0; 


#define SlpQRt 1L //this is the fastest rate any method can run 
int done = 0; 
while(done = 0){ 

done = pSQ->CkQQO; 

Sleep(SlpQRt); 


}//endforever 


return(dwResult); 
}//end_ThreadFunc() 


// zpb_end 


// Pane Member Functions - Trk WinTrkPane 
Trk WinTrkPane::Trk WinTrkPane(z Window *w, zSizer *sz) : zPane(w, sz, WS_CHILD|WS_BORDER) { 


// zpb_begin pTrk WinTrkPaneConstnuctor] 


//this is where we determine which track to display 
bmpha = new zBitmap(canvas(, "sym/diamup.bmp” ); 
bmphs =new zBitmap(canvas(), “sym/diamdwn.bmp" ); 
bmphsf =new zBitmap(canvas(), “sym/diam.bmp” _); 
bmpukna = new zBitmap(canvas(), "sym/sqrup.bmp” ); 
bmpukns = new zBitmap(canvas(), “sym/sqrdwn.bmp” ); 
bmpuknsf = new zBitmap(canvas(), “sym/sqr.bmp" _); 
bmpfa =new zBitmap(canvas(, “sym/circleup.bmp” ); 
bmpfs =new zBitmap(canvas(), “sym/circledwn.bmp”"); 
bmpfsf = new zBitmap(canvas(), “sym/circle.bmp” ); 

// zpb_end 
show(); 
} 


int Trk WinTrkPane::mouseButtonDown(zMouseClickEvt* ev) { 


if (ev->isButton(1)) { // Left Button Pressed 
/! zpb_begin Trk WinTrkPaneLButtonDown 

int DTndx = 0; 

zPoint mpos; 


mpos = ev->pos(); //gives us the position when clicked 
int mousex = mpos.x(); 
int mousey = mpos.y(); 
int closex = pTQ->TQ[DTndx]->xpos; 
int closey = pTQ->TQ[DTndx]->ypos; 

| pIQ->DTindx = DTndx; 
for(DTndx=1;DTndx<pTQ->nTrks;DTndx++) { 
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} 


if( ( abs(pTQ->TQ{DTndx]->xpos - mousex) 


< abs( closex - mousex)) 
&&( abs(pTQ->TQ[DTndx]->ypos - mousey) 
< abs( closey - mousey))){ 


closex = pTQ->TQ[DTndx]->xpos; 

closey = pTQ->TQ[DTndx]->ypos; 

pTQ->DTindx = DTndx; //update the DTInfo() ndx 
} //endif 

}//endfor 


DTInfo* p=ZNEW DTinfo(this, zResid(IDD_Tinfo)); 
p->modal(); 
if (p->completed()) { 
// hook for later code 
pTQ->TQ[pTQ->DTindx]->distype = p->UpdAtt(pTQ->TQ[pTQ->DTindx]->dTypSt); 
} //endif 
delete p; 


// zpb_end 

} 

else 

if (ev->isButton(2)) { // Right Button Pressed 

// zpb_begin Trk WinTrkPaneRButtonDown 

int NIndx = 0; 

zPoint mpos; 

mpos = ev->pos(); //gives us the position when clicked 

int mousex = mpos.x(); 

int mousey = mpos.y(); 

int closex = pTQ->TQ{0]->xpos; 

int closey = pTQ->TQ([0]->ypos; 

pIQ->newTrkTxt = 0; 

for(NTIndx=1! ;NTndx<pTQ->nTrks;NTndx++) { 
if( ( abs(pTQ->TQ[NTndx]->xpos - mousex) 


< abs( closex - mousex)) 
&&({ abs(pTQ->TQ[NTndx]->ypos - mousey) 
< abs( closey - mousey))) { 


closex = pTQ->TQ[NTndx]->xpos; 

closey = pTQ->TQ[NTndx]->ypos; 

pIQ->newTrkTxt=NTndx; //update the TrkTxt() ndx 
}//endif 

}//endfor 


const char tkmsg[256] = "Track Analysis"; 

/strcat(trkmsg, pTQ->TQ[NTndx]->numSt); 

if(pTQ->TQ[pTQ->newTrkTxt] != NULL){ //Track must exist 

if(pTQ->TQ[pTQ->newTrkTxt}->TxWn == NULL){ //Only one window per track 
ZNEW WTrkTxt((zMDIAppFrame* )zAppGetAppVar(app)->root Window(, trkmsg); 

} //endif 

} //endif 


/ zpb_end 


} 
return 0; 


int Trk WinTrkPane::size({zSizeEvt *ev) { 


} 


setDirty(); 

/! zpb_begin Trk WinTrkPaneSize 
/! zpb_end 

return zWindow::size(ev); 


int Trk WinTrkPane::draw(zDrawEvt* ev) { 


canvas{)->lock(); 
/! zpb_begin TrkPaneDraw 
/Nocal constants 


130 


/Nocal vanables 


//clear the window pane 

zRect DxTxtArea; 

canvas(}->getVisible(DxTxtArea); 
canvas(}->pushPen(new zPen(zColor(GREEN), Solid, 5)); 
canvas()->pushBrush(new zBrush(DarkGrayBmush)); 
canvas()}->pushBnuish(new zBrush(zColor(0,0,0))); 
canvas()->rectangle{ Dx TxtArea); 

delete canvas(}->popPen(); 

delete canvas()->popBrushQ); 


//set up the display parameters 

// — select a newly created font 

/canvas(->backColor(zColor(0,0,0)); 
canvas()->setTextBackMode(ZTEXT_TRANSPARENT); 
canvas()->pushFont(new zFont("Helv",zPrPoint{12,25,canvas()),900,ffDontCare)); 


//draw a line - will use the pen 

int ndx; 

for(ndx=0;ndx<pTQ->nTrks;ndx++){ 
canvas()->textColor(pTQ->TQ|[ndx}->clr); 
canvas()->pushPen(new zPen(pTQ->TQ|[ndx]->clr,Solid,1)); 
float xtmp,ytmp; 
int x,y; 
#define WINDLT 3 


xtmp= ((float)DxTxtArea.widthQ) 
* ((pTQ->TQ[ndx}->xRaw - pTQ->minlt)/pTQ->dellt); 

x = DxTxtArea_left() + (int)xtmp; 

if{x<=(DxTxtArea. left + WINDLT)){ 
x=DxTxtArealeft() + WINDLT; 

}//endif check lower bound 

if{x>=(DxTxtArea_right0Q- WINDLT)){ 
x=DxTxtArearnight() - WINDLT; 

}//check upper bound 


ytmp = ((float)DxTxtAreaheight()) 
* ((pTQ->TQ[ndx]->yRaw - pTQ->minlg)/pTQ->dellg); 
y = DxTxtAreatop( + (int)ytmp; //new y for display 


if(y<=(DxTxtArea.top(Q) + WINDLT)){ 
y=DxTxtAreaztop0 + WINDLT; = //clip to top of window 
}//endif check lower bound 


if(y>=(DxTxtArea.bottom()- WINDLT)) { 

y=DxTxtArea.bottom( - WINDLT; //clip to bottom of window 

}//check upper bound 

switch(pTQ->TQ[ndx]->distype) { 

case HOSTILE_AIR: 
canvas()->bitmap(bmpha,zPoint{x-10,y-20), SRCCOPY); 
canvas()->textColor(zColor(255,0,0)); 
canvas()->text(x-11, y,pTQ->TQ|[ndx]->numSrt); 
if( (PTQ->TQ[ndx}->xpos != 0) 
(PT Q->TQ([ndx]->ypos != 0)){ 
canvas()->move To(x,y); 
canvas()->lineTo(pTQ->TQ[ndx]->xpos, pT Q->TQ|[ndx]->ypos); 
}//endif 
plQ->TQ|[ndx]->xpos = x; 
pIQ->TQ|[ndx]->ypos = y; 
break; 
case HOSTILE_SUB: 
canvas()->bitmap(bmphs,zPoint{x-10,y), SRCCOPY); 
canvas()->textColor(zColor(255,0,0)); 
canvas()->text(x-11, y+20,pTQ->TQ|[ndx]->numSt); 
if{ (pTQ->TQ[ndx]->xpos != 0) 
(PTQ->TQ[ndx]}->ypos != 0)){ 

canvas()}->moveTo(x,y); 
canvas()->line To(pTQ->TQ|[ndx]->xpos,pTQ->TQ|[ndx]->ypos); 
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}//endif 
pIQ->TQ([ndx]->xpos = x; 
pIQ->TQ[ndx]->ypos = y; 
break; 

case HOSTILE_SURFACE: 
canvas()->bitmap(bmphsf,zPoint(x-12,y-12), SRCCOPY); 
canvas()}->textColor(zColor(255,0,0)); 
canvas()->text(x-12, y+1 1,pTQ->TQ[ndx]->numStr); 
if{ (pTQ->TQ[ndx]->xpos != 0) 

I(pPTQ->TQ[ndx]->ypos != 0)){ 
canvas()->moveTo(x,y); 
canvas()->lineTo(pTQ->TQ|[ndx]->xpos,pTQ->TQ[ndx]->ypos); 
‘endif 
pI Q->TQ[ndx]->xpos = x; 
pI Q->TQ([ndx]->ypos = y; 
break; 

case UNKNOWN_AIR: 
canvas()->bitmap(bmpukna,zPoint(x-10,y-20), SRCCOPY); 
canvas(}->textColor(zColor(255,255,255)); 
canvas()->text(x-12, y,pTQ->TQ[ndx]->numStr); 
if{ (pTQ->TQ[ndx]->xpos != 0) 

IPTQ->TQ[ndx]->ypos != 0)){ 
canvas(}->moveTo(x,y); ° 
canvas()->lineTo(pTQ->TQ|[ndx]->xpos,pT Q->TQ|[ndx]->ypos); 
} //endif 
pT Q->TQ[ndx]->xpos = x; 
pIQ->TQ(ndx]->ypos = y; 
break; 

case UNKNOWN_SUB: 
canvas()->bitmap(bmpukns,zPoint(x-10,y), SRCCOPY); 
canvas()->textColor(zColor(255,255,255)); 
canvas()->text(x-12, y+20,pTQ->TQ([ndx]->numSt); 
if( (pPTQ->TQ[ndx]->xpos != 0) 

(PTQ->TQ[ndx]->ypos != 0)){ 
canvas(}->moveT o(x,y); 
canvas()->lineTo(pTQ->TQ[ndx]->xpos,pTQ->TQ[ndx]->ypos); 
}//endif 
pTQ->TQ[ndx]->xpos = x; 
pI Q->TQ[ndx]->ypos = y; 
break; 

case UNKNOWN_SURFACE: 
canvas(}->bitmap(bmpuknsf,zPoint(x-10,y-10), SRCCOPY); 
canvas()->textColor(zColor(255,255,255)); 
canvas()}->text(x-11, y+10,pTQ->TQ[ndx]->numSt); 
if( (PTQ->TQ[ndx]->xpos != 0) 

II(PTQ->TQ[ndx]->ypos != 0)){ 
canvas()->moveT0(x,y); 
canvas()->lineTo(pTQ->TQ[ndx]->xpos,pTQ->TQ[ndx]->ypos); 
} //endif 
pT Q>TQ([ndx]->xpos = x; 

PTQ->TQ([ndx]->ypos = y; 
break; 

case FRIENDLY_AIR: 
canvas()->bitmap(bmpfa,zPoint(x-8,y-17), SRCCOPY); 
canvas(}->textColor(zColor(0,255,255)); 
canvas(}->text(x-9, y+] ,.pTQ->TQ[ndx]->numStr); 
if( (pPTQ->TQ[ndx]->xpos != 0) 

H(PTQ->TQ[ndx]->ypos != 0)){ 
canvas()->moveT 0(x,y); 
canvas()->lineTo(pTQ->TQ[ndx]->xpos,pTQ->TQ[ndx]->ypos); 
} //endif 
pIQ->TQ([ndx]->xpos = x; 
pTQ->TQ[ndx]->ypos = y; 
break; 

case FRIENDLY_SUB: 
canvas()}->bitmap(bmpfs,zPoint(x-8,y), SRCCOPY); 
canvas(}->textColor(zColor(0,255,255)); 
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I 


canvas()->text(x-9, y+18,pTQ->TQ{ndx]->numSt); 
if( (pTQ->TQ|[ndx]}->xpos != 0) 

I(PTQ->TQ[ndx}->ypos != 0)){ 
canvas(}->moveTo(x,y); 
canvas()->lineTo(pTQ->TQ{[ndx ]->xpos,pTQ->TQ[ndx]->ypos); 
endif 
pTQ->TQ[ndx]->xpos = x; 
plQ->TQ[ndx]->ypos = y; 
break; 

case FRIENDLY_SURFACE: 
canvas()->bitmap(bmpfsf,zPoint(x-11,y-11), SRCCOPY); 
canvas()}->textColor(zColor(0,255,255)); 
canvas(}->text(x-11, y+12,pTQ->TQ[ndx]->numSt); 
if{ (PTQ->TQ[ndx]->xpos != 0) 

(PTQ->TQ[ndx]}->ypos != 0)){ 
canvas()->moveT0o(x,y); 
canvas()->lineTo(pTQ->TQ[ndx]->xpos,pTQ->TQ[ndx]->ypos); 
}//endif 
pTQ->TQ[ndx]->xpos = x; 
pfQ->TQ{ndx]->ypos = y; 
break; 

}; /lend case statement 
MpTQ->TQ[ndx]->distype++; 
/Af (pTQ->TQ[ndx]->distype > 8)pTQ->TQ|[ndx]->distype = 0; 
Hcanvas()->text(x, yp TQ->TQ[ndx]->numStr); 
delete canvas()}->popPen(Q); 
}//endfor ndx 


/canvas()->textColor(BLACK); 
delete canvas()->popFontQ); 


// zpb_end 
canvas()->unlockQ); 
return 1; 


// Frame Member Functions - Trk Win 


Ml 


// Window Constructor 
WIrk Win::WTrk Win(zMDIAppFrame *w, const char *title) 


} 


: zMDIChildFrame(w,ZNEW ZSizer(zDialogUnit(310,0), zDialogUnit(200, 155)),zSTDFRAME, title) { 


// zpb_begin WTrk WinConstructor2 


drwRt=500L; 

drwTm=0L; 

#define TRSR 10L // this object wakes up at the fastest message freq. 

/! zpb_end 

deleteOnClose(TRUE); 

menu(ZNEW zMenu(this, zZResId(IDM_Trk WinTrkMenu))); 

menu()->setCommand(this, (CommandProc)& WT rk Win::cmdControlAutoSet, IDM_CONTROLAUTOSET); 
menu()->setCommand (this, (CommandProc)& WTrk Win::cmdControlRefresh, IDM_CONTROLREFRESH); 
menu()->setCommand(this, (CommandProc)& WT rk Win::cmdControlSetup, IDM_CONTROLSETUP); 
menu()->setCommand(this, (CommandProc)& WT rk Win::cmdDisplayTrack, IDM_DISPLAYTRACK); 
pIrkPane = ZNEW Trk WinTrkPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizer())); 

pI rkPane->showQ); 

sizer()->update(); 

/f zpb_begin WTrk WinConstructor 

/fpStaticlcon] ->backgroundColor(zColor(64,64,64)); 

pSQ->Slp(this, TRSR); //wake window every x ticks 

/! zpb_end 

show(); 


WTrk Win::~WTrk WinQ) { 


// zpb_begin WTrk WinDestructor] 
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} 


Mf 


pSQ->Rm(this); //Remove this window from the sleep queue 


pTQ->~TrkQ(); 
// zpb_end 


// Menu Item Selection Handlers 


Mf 


int WIrk Win::cmdControlAutoSet(zCommandEvt* ev) { 


} 


/{ zpb_begin WTrk WinControlAutoSet 
pTQ->rescale(); 

// zpb_end 

return 0; 


int WI rk Win::cmdControlRefresh(zCommandEvt* ev) { 


} 


DTrkRfsh* p=ZNEW DTrkRfsh(this, zResid(IDD_TrkRfsh)); 
p->modal(); 

if (p->completed()) { 

// zpb_begin WTrk WinControlRefresh 

drwRt = (unsigned long) atol(p->_DRv); 

// zpb_end 

} else { 

/f zpb_begin WTrk WinControlRefreshCancel 
// zpb_end 

} 

delete p; 

return 0; 


int WIrk Win::cmdControlSetup(zCommandEvt* ev) { 


} 


DTkSet* p=ZNEW DTkSet{this, zResid(IDD_TkSet)); 
p->modal(); 

if (p->completed()) { 

// zpb_begin WTrk WinControlSetup 

p1Q->minlt = p->_laMn; //this is for op area field of view 
plQ->maxit = p->_laMx; 

pT Q->minig = p->_lgMn; 

pl Q>maxlg = p->_lgMx; 

plQ->dellt = pTQ->maxlt - pTQ->minit; 

plQ->dellg = pTQ->maxlg - pTQ->minlg; 

/! zpb_end 

} else { 

// zpb_begin WTrk WinControlSetupCancel 

// zpb_end 

} 

delete p; 

return 0; 


int WI rk Win::cmdDisplayTrack(zCommandEvt* ev) { 


} 


ZNEW WIrkTxt((zMDIAppFrame* )zAppGetA pp Var(app)->root Window(), zString(zResid(@DS_TRKTXT))); 
/f zpb_begin WTrk WinDisplayTrack 

// zpb_end 

return 0; 


// zpb_begin WTrk WinMemberF unctions 
int WIrk Win::wake() { 


return 0; 


zDrawEvt *tmpEv; 
if(pSQ->systime >= drwTm){ 
pIrkPane->draw(tmpEv); 
drwTm = pSQ->systime + drwRt 
}//endif 


}//end wake() 
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// zpb_end 


// Pane Member Functions - Sym WinSymPane 
SymWinSymPane::Sym WinSymPane(zWindow *w, zSizer *sz) : ZPane(w, sz, WS_CHILD) { 


// zpb_begin pSym WinSymPaneConstructor] 
/! zpb_end 
show(); 

} 


int Sym WinSymPane::size(zSizeEvt *ev) { 


setDurty(); 
/! zpb_begin Sym WinSymPaneSize 
/! zpb_end 
retum zWindow::size(ev); 
} 


mt Sym WinSymPane::draw(zDrawEvt* ev) { 
canvas()->lock(); 
/! zpb_begin SymPaneDraw 
//set up the display parameters 
canvas()->pushFont(new zFont("Helv",zPrPoint(12,25,canvas()),900,ffDontCare)); 


/{clear the window pane 

zRect DxTxtArea; 
canvas()->getVisible(DxTxtArea); 
canvas()->rectangle(DxTxtArea); 


canvas()->text(10, 
10, 
“hello world"); 


delete canvas()->popFont(); 
/! zpb_end 
canvas()->unlock(Q); 

return |; 


Hf 

// Frame Member Functions - Sym Win 

Hf 

// Window Constructor 

WSym Win::WSym Win(zMD1IAppFrame *w, const char *title) 

: ZMDIChildFrame(w,ZNEW ZSizer(zDialogUnit(3 10,0), 
zDialogUnit(200,255)),WS_CHILD|WS_THICKFRAME|WS SYSMENU|WS_MINIMIZEBOX|WS_CAPTION, title) { 
/! zpb_begin WSym WinConstructor2 


// zpb_end 
deleteOnClose(TRUE); 
menu(ZNEW zMenu(this, zZResId(IDM_SymWinSymMenu))); 
menu()->setCommand(this, (CommandProc)& WSym Win::cmdControlRefresh, IDM_CONTROLREFRESH); 
pSymPane = ZNEW SymWinSymPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizerQ)); 
pSymPane->show(); 
sizer()->update(); 
/! zpb_begin WSym WinConstructor 
// zpb_end 
show(); 
} 


WSym Win::~WSymWinQ { 


/1 zpb_begin WSym WinDestructor! 
/! zpb_end 
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// Menu Item Selection Handlers 
If 


int WSymWin::cmdControlRefresh(zCommandEvt* ev) { 
DSymRfsh* p=ZNEW DSymRfsh(this, zResId(IDD_SymRfsh)); 
p->modal(); 
if (p->completed()) { 
// zpb_begin WSym WinControlRefresh 
// zpb_end 
} else { 
// zpb_begin WSym WinControlRefreshCancel 
// zpb_end 
} 
delete p; 
retum 0; 
} 


// zpb_begin WSym WinMemberFunctions 
/1 zpb_end 


// Pane Member Functions - Del WinSymPane 
DelWinSymPane::Del WinSymPane(zWindow *w, zSizer *sz) : zZPane(w, sz, WS_CHILD) { 


// zpb_begin pDel WinSymPaneConstructor1 
// zpb_end 
show(); 

} 


int Del WinSymPane::size(zSizeEvt *ev) { 
setDutyQ); 
// zpb_begin Del WinSymPaneSize 
// zpb_end 
retum zWindow::size(ev); 


} 


int DelWinSymPane::draw{zDrawEvt* ev) { 
canvas({)->lockQ); 
// zpb_begin SymPaneDraw 
//set up the display parameters 
canvas()->pushFont(new zFont("Helv",zPrPoint{12,25,canvas()),900,ffDontCare)); 


//clear the window pane 

zRect DxTxtArea; 
canvas()->getVisible(DxTxtArea); 
canvas()->rectangle(DxTxtArea); 


canvas()->text{10, 
10, 
“hello world"); 


delete canvas()->popF ont(); 
/f zpb_end 
canvas()->unlock(); 

return |; 


// 

// Frame Member Functions - Del Win 

// 

// Window Constructor 

WDel Win::WDel Win(zMDIAppFrame *w, const char *title) 

: ZMDIChildFrame(w,ZNEW 2zSizer(zDialogUnit(3 10,255), 
zDialogUnit(200,112)),WS_CHILD|WS_THICKFRAME|WS_SYSMENU|WS_MINIMIZEBOX|WS_CAPTION, title) { 
// zpb_begin WDel WinConstructor2 
// zpb_end 
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deleteOnClose(TRUE); 
menu(ZNEW zMenu(this, zZResId(IDM_DelWinSymMenu))); 
menu()->setCommand(this, (CommandProc)& WDelWin::cmdControlRefresh, IDM_CONTROLREFRESH); 
pSymPane = ZNEW DelWinSymPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizer())); 
pSymPane->show(); 
sizer()->update(); 
/! zpb_begin WDelWinConstructor 
/! zpb_end 
show(); 
} 


WDelWin::~WDelWinQ) { 
// zpb_begin WDel WinDestructor! 
/! zpb_end 

} 


i 
//Menu Item Selection Handlers 
i 


int WDel Win::cmdControlRefresh(zCommandEvt* ev) { 
DSymRfsh* p=ZNEW DSymRfsh(this, zZResId(IDD_SymRfsh)); 
p->modal(); 
if (p->completedQ) { 
/! zpb_begin WDelWinControlRefresh 
// zpb_end 
} else { 
// zpb_begin WDelWinControlRefreshCancel 
/! zpb_end 
} 
delete p; 
return 0; 


} 


/l zpb_begin WDelWinMemberFunctions 
/l zpb_end 


// Pane Member Functions - TrkTxtTkTxPane 
Tek TxtTkTxPane::TrkTxtTkTxPane(zWindow *w, zSizer *sz) : zZPane(w, sz, WS_CHILD) { 


// zpb_begin pTrkTxtTkTxPaneConstructor] 
TrkNdx = pTQ->newTrkTxt; //set the track pointer to the New Track 
/! zpb_end 
show(); 

} 


nt TrkTxtTkTxPane::size(zSizeEvt *ev) { 
setDirty(); 
/! zpb_begin TrkTxtTkTxPaneSize 


// zpb_end 
return zWindow::size(ev); 


ot [rk TxtTkTxPane::draw(zDrawEvt* ev) { 


canvas(}->lockQ; 
/! zpb_begin TkTxPaneDraw 
Nocal constants 
‘define N_TKMSGS 24 // total number of messages displayed on the pane 
‘define X_MB3  //x coordinate for base (first row) of display messages 
define Y MB 10 // y coordinate for base (first row) of display messages 
“define R_OFF 15 = //offset for spacing between rows 
/Nocal variables 
int tmp_ndx; //temporary index 
. int IbufNdx; 
| int r_ndx; /frow index for looping through the active messages currently displayed 
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int r_ curr; //actual index into the buffer of messages 
‘char *msg_curr[N_TKMSGS]; 


//set up the display parameters 
//canvas()->pushF ont(new zFont("Helv",zPrPoint(12,25,canvas()),900,ffDontCare)); 
canvas()->pushFont(new zFont("Helv”,zPrPoint(12,25,canvas()),900,ffDontCare)); 


//clear the window pane 

zRect DxTxtArea; 

canvas()->getVisible(DxTxtArea); 
/Icanvas()->pushPen(new zPen(zColor((GREEN), Solid, 5)); 
canvas()->pushBrush(new zBrush(zColor(255,255,255))); 
canvas()->rectangle(DxTxtArea); 

//delete canvasQ->popPen(); 

delete canvas()->popBrush(); 


//set up the display parameters 

// ~ select a newly created font 
/Icanvas()->backColor((GRAY); 
canvas()}->setTextBackMode(ZTEXT_TRANSPARENT); 


int nMsgs; 
if(pTQ->TQ[TrkNdx}->MQndx < N_TKMSGS) { 
nMsgs = pTQ->TQ[TrkNdx]->MQndx; 
r_ndx = 0; 
} else { 
nMsgs = N_TKMSGS; 
r_ndx = pTQ->TQ[TrkNdx]->MQndx - N_TKMSGS; 
‘//endif 


zDimension txtDim; //used to move the draw origin as chars output 
int xdelta; //number of pixels for chars draw on a line 
canvas()->textColor(zColor(0,0,0)); //black text 
char *ptcl; 
char *ptc0; 
char *ptcm1; 
int numchrs; 
int ndx; 
int dsum; 
for(tmp_ndx=(nMsgs-1);tmp_ndx>=0;tmp_ndx—) //loop through the number of 
/fines displayed in the window 
r_curr = r_ndx+tmp_ndx; 


zPoint p{ X_MB, 
(Y_MB+(((nMsgs-1)-tmp_ndx)*R_OFF))); 
int scnt{LBUFSZ]; 
xdelta = 0; 
if((nMsgs>1 )&&(r_curr>0)){ 
ptecl = pTQ->TQ[TrkNdx]->MQ[r_curr}; //get pointer to line buffers 
ptcO = pTQ>TQ[TrkNdx]->MQ[r_curr-1]; 
numchrs = strlen(ptcl ); 
dsum = 0; 
int cent; 
for(ccnt=0;(ccnt<numchrs)& &(ccnt<LBUFSZ);ccnt++) { 
if( ((*pte1) != (*ptc0))) { 
sent[ccnt] = 1; 
plQ>TQ[TrkNdx]->CurDel[ccnt] = 1; 
dsum++; //this counts number of chars not same 
yelse{ 
scnt[ccnt] =0; 
pTQ->TQ[TrkNdx]->CurDel[cent] = 0; 
}//endif 
ptcl++; 
ptcO++; 
}//endfor 
if((nMsgs>2)&&(r_curr>1)){  /Aest for "delta messaging” 
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ptcO = pTQ->TQ[TrkNdx]->MQ[r_curt-1}; //reset pointer to line buffers 
ptcm] = pTQ->TQ[TrkNdx]->MQJr_curr-2]; 
for(ccnt=0;(ccnt<numchrs)&&(cent<LBUFSZ);ccnt++) { 
if((* ptcO) != (*ptcem1)){ 
pTQ->TQ[TrkNdx]->OldDel{cent} = 1; 
Jelse{ 
pl Q->TQ[TrkNdx]->OldDel[ccnt} = 0; 
}/endif 
ptcO++; 
ptcm|++; 
}//endfor 
Viendif 
ptcl = pTQ->TQ[TrkNdxj->MQ[r_curr}; //reset pointer to line buffer 
int pent; 
cent=0; 
while((ccnt<numchrs)&&(ccnt<LBUFSZ)) { 
pent = 0; 
while(scnt{[ccnt}=0) { 
pcnt++;ccnt++; 
}//endwhile 
if((pent>0)&&(ccnt<=numchrs)) { 
canvas()->textColor(zColor(0,0,0)); //black text if same 
zPoint dc(p.xQ) + xdelta,p.y(Q); 
canvas()->text(dc,ptc1 ,pcnt); 
txtDim = canvas()->getTextDim(ptc1 ,pent); 
xdelta += (txtDim.width(Q-1); 
ptcl += pent; 
//endif 


if{ccnt<numchrs) { 
canvas()->textColor(zColor(255,0,0)); //red text if different 
zPoint ddc(p.x() + xdelta,p.yQ); 
canvas(}->text(dde,ptc1,1); 
txtDim = canvas()->getTextDim(ptc1,1); 
xdelta += (txtDim.widthQ-1); 
cent++; 
ptcl++; 

}/endif 

}//endwhile 


int dmsg = 0; // test to see if we have a delta message 
int tndel = strlen(pTQ->TQ[TrkNdx}->timStr) + 1; 
for(ccnt=tmdel; 
((ccnt<numchrs)&&(ccnt<LBUFSZ)); 
ccnt++ ){ 
if( ( pTQ->TQ[TrkNdx}->CurDel[ccnt} = 1 ) //we have anew char 
&&( pTQ->TQ[TrkNdx]->OldDel[ccnt}] = 0 )){ //no delta message 
dmsg++; 
}//endif 
}//endfor 


xdelta = 700; 
ptel = pTQ->TQ[TrkNdx]->MQ[r_curr]; //reset pointer to curr buffer 
ptcl += tmdel; 
iff(dmsg == 0){ //we have a delta message 
char dm[8]} = “!!!"; 
canvas(}->textColor(zColor(0,0,255)); //blue text 
zPoint ddce(p.x() + xdelta,p.yQ); 
canvas()->text(ddc,dm,1); 
txtDim = canvas()->getTextDim(dm, 1); 
xdelta += (txtDim.width()-1); 
for(ccnt=tmdel; 
(ccnt<numchrs)&&(ccnt<LBUFSZ); 
ccont++ { 
if( pTQ->TQ[TrkNdx]->OldDel{[ccnt} == 1 ){ //print the delta char 
if{ccnt<numchrs) { 
canvas()->textColor(zColor(0,0,255)); //blue text 
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zPoint ddc(p.xQ) + xdelta,p.yQ)); 
canvas({)->text(ddc,ptc 1,1); 
txtDim = canvas()->getTextDim(ptc 1,1); 
xdelta += (txtDim.width()-1); 
}//endif 
endif 
ptcl++; 
}//endfor 


} else { 


char dm[8] = "772"; 
canvas()}->textColor(zColor(0,0,0)); //black text 
zPoint ddc(p.xQ) + xdelta,p.yQ); 
canvas()->text(ddc,dm, 1); 
txtDim = canvas()->getTextDim(dm, | ); 
xdelta += (txtDim.width()-1); 

‘//endif 


//the following calculates values needed for the analysis window 

numchrs -= 100; //this adjusts for extra constant chars in the strings 
if(numchrs<0) {numchrs=0;} 

if(numchrs<dsum) {dsum=numchrs;} 

pIQ->TQ[TrkNdx]->cCnt[r_curr] = numchrs; //store total number of chars 
pTQ->TQ[TrkNdx]->dCnt[r_curr] = dsum; 


if(numchrs>0){ 
pIQ->TQ[TrkNdx]->csRatio[r_curr] = ((float)dsum/(float)numchrs); 
else { 
pIQ->TQ[TrkNdx]->csRatio[r_curr] = 0.0; 
}//endif 
selse{ 
canvas()->textColor(zColor(255,0,0)); //red text if first message 
canvas()->text(p, 
pIQ->TQ[TrkNdx]->MQ[r_curr]); 
}//endif 
canvas()->textColor(zColor(0,0,0)); //black text is default 
}//endfor 
delete canvas()->popFont(); 
// zpb_end 
canvas()->unlockQ; 
return |; 


// Frame Member Functions - TrkTxt 


// Window Constructor 
WTrkTxt::WIrkTxt(zZMDIAppFrame *w, const char *title) 
: ZMDIChildFrame(w,ZNEW zSizer(zDialogUnit(-2,97), 


zDialogUnit(310,167)),WS_CHILD|WS_THICKFRAME|WS_SYSMENU|WS_MINIMIZEBOX!WS_CAPTION, title) { 
// zpb_begin WTrkTxtConstructor2 
if{(pT Q->nTrks>0){ 

zRect wsz; 

zCoOrd xd; 

zCoOrd yd; 

getExterior(wsz); 

xd = pTQ->xdTrkT xt; 

yd = pTQ->ydTrkTxt; 

zPoint tmppt(xd,yd), 

wsz+=tmppt; 

move(wsz); 

pIQ->xdTrkTxt -= 5; 
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prQ->ydTrkTxt += 50; 


}//endif 
/! zpb_end 
deleteOnClose(TRUE); 
backgroundColor(zColor(0,255,255)); 
menu(ZNEW zMenu(this, zResid(IDM_TrkTxtTkTxMenu))); 
menu()->setCommand(this, (CommandProc)& WTrkTxt::cmdAnalysis Throughput, IDM_ANALYSISTHROUGHPUT); 
menu()->setCommand(this, (CommandProc)& WTrkTxt::cmdControlRefresh, IDM _CONTROLREFRESH); 
pTkTxPane = ZNEW TrkTxtTkTxPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizer())); 
pIkTxPane->show(); 
sizer()->update(); 
// zpb_begin WTrkTxtConstructor 
p1Q->TQ[pTQ->newTrkTxt}->TxWhn = this; //this is a message text display window 
pTQ->newTrkAn = pTkTxPane->TrkNdx; 
ZNEW WDatAn((zMDIAppFrame* )zAppGetAppVar(app)->root Window(), zString(zResId(IDS_DATAN))); 
// zpb_end 
showQ); 
} 


WIrkTxt::-~WTrkTxtQ) { 
/! zpb_begin WTrkTxtDestructor] 
pTQ->TQ[pTkTxPane->TrkNdx]->Tx Wn = NULL; //this is a message text display window 
pIkTxPane->TrkNdx = 0; 
// zpb_end 
} 


i 
// Menu Item Selection Handlers 
If 


int WIrkTxt::cmdAnalysisThroughput(zCommandEvt* ev) { 
ZNEW WDatAn((zMDIAppFrame* )zAppGetA ppVar(app)->root Window(), zString(zResId(IDS_DATAN))); 
// zpb_begin WTrkTxtAnalysis Throughput 
/pTQ->newTrkAn = pTkTxPane->TrkNdkx; 
/! zpb_end 
return 0; 


} 


int WIrkTxt::cmdControlRefresh(zCommandEvt* ev) { 
DSymRfsh* p=ZNEW DSymRfsh(this, zZResId(IDD_SymRfsh)); 
p->modal(); 
if (p->completed()) { 
/! zpb_begin WTrkTxtControlRefresh 
/! zpb_end 
} else { 
/} zpb_begin WTrkTxtControlRefreshCancel 
// zpb_end 
} 
delete p; 
return 0; 


} 
: 1 zpb_begin WIrkTxtMemberf unctions 


‘int WIrkTxt::rtrdrw() { 
zDrawEvt *dummyEv; 
pTkTxPane->draw(dummyEv); /Athe draw routine does not use this input param 
/! zApp uses this as an event token for its 
/1 own dispatching. 
return 0; 


}Hend rrdrw() 


/zpb_end 


'/ Pane Member Functions - DatAnDatAnPane 
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DatAnDatAnPane::DatAnDatAnPane(zWindow *w, zSizer *sz) : zZPane(w, sz, WS_CHILD) { 


// zpb_begin pDatAnDatAnPaneConstructor1 
TrkNdx = pTQ->newTrkAn; 
// zpb_end 
show(); 
} 


int DatAnDatAnPane::size(zSizeEvt *ev) { 
setDirty(Q); 
// zpb_begin DatAnDatAnPaneSize 
// zpb_end 
return zWindow::size(ev); 

} 


int DatAnDatAnPane::draw(zDrawEvt* ev) { 


canvas()->lockQ; 
// zpb_begin DatAnPaneDraw 
/Nocal constants 
#define N_-TKMSGS 24 // total number of messages displayed on the pane 
#define X_MB3  //x coordinate for base (first row) of display messages 
#define Y_MB 10 // y coordinate for base (first row) of display messages 
#define RLOFF 15 _= //offset for spacing between rows ° 
/Aocal variables 
int tmp_ndx; /Aemporary index 
int lbufNdx; 
int r_ndx; /row index for looping through the active messages currently displayed 
int r_curr; //actual index into the buffer of messages 


//char *msg_curr[N_TKMSGS]; 


//set up the display parameters 
/canvas()->pushFont(new zFont("Helv",zPrPoint(12,25,canvas()),900,ffDontCare)); 
canvas()->pushFont(new zFont("Helv",zPrPoint(12,25,canvas()),900,ffDontCare)); 


//clear the window pane 

zRect DxAnArea; 

canvas()->getVisible(DxAnArea); 
//canvas()->pushPen(new zPen(zColor(GREEN), Solid, 5)); 
canvas()->pushBrmush(new zBrush(LiteGrayBrush)); 
canvas()->rectangle(DxAnArea); 

//delete canvas()->popPenQ); 

delete canvas()->popBrushQ); 


canvas()->setTextBackMode(ZTEXT_TRANSPARENT); 


int nMsgs; 
if(pTQ->TQ[TrkNdx]->MQndx < N_TKMSGS){ 
nMsgs = pTQ->TQ[TrkNdx]->MQndx; 
r_ndx = 0; 
} else { 
nMsgs = N_TKMSGS; 
r_ndx = pTQ->TQ[TrkNdx]->MQndx - N_TKMSGS; 
} //endif 


char tbuf]256]; 
char tmp[16]; 
ostrstream tmpstr(tbuf,strlen(tbuf)); 


int x in; 

X_margin = int (0.05*((float)DxAnArea.widthQ)); 

int y_margin; 

y_margin = int (0.125*((float)DxAnArea_height())); 

int c_ off; 

c_off = int (0.9*((float)DxAnArea.width))/N_TKMSGS); 
int maxchrs = 30; 
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/ 


int y_unit; 
y_unit = (DxAnArea_height()- (2*y_margin))/maxchrs; 


canvas(}->text{5, 
=. 
plQ->TQ[TrkNdx]->numSt); 
canvas()->text(50, 
> 
pfQ->TQ[TrkNdx]->timSt); 


for(tmp_ndx=(nMsgs-1 );tmp_ndx>=0;tmp_ndx--) /Jloop through the number of 
{ /Nines displayed in the window 
r_curr=r_ndx+tmp_ndx; 


if((nMsgs>1)&&(r_curr>0)){ 
canvas()}->pushPen(new zPen(zColor(GREEN), Solid, 5)); 
canvas()->moveTo(x_margin+{(((nMsgs-1}-tmp_ndx)*c_off)), 
DxAnArea.bottom() - y_margin ); 
/Aempstr << dec << pTQ->TQ[TrkNdx]->dCnt{r_curr]}<<"\0"; 
/Isweepy(tmp,tbuf); 
/Ant tbufndx = strien(tmp}-1; 
/Aemp[tbufndx}='\0'; 


canvas()->lineTo(x_margin+((((nMsgs-1)-tmp_ndx)*c_off)), 
( (DxAndArea.bottom() - y_margin ) 
-(y_unit * pTQ->TQ[TrkNdx}->cCnt[r_curr]))); 
delete canvas()->popPen(); 
canvas()->pushPen(new zPen(zColor(RED), Solid, 5)); 
canvas()}->moveTo(x_margin+({(((nMsgs-1)-tmp_ndx)*c_ off), 
DxAnArea.bottom() - y_margin ); 
canvas()->lineTo(x_margin+((((nMsgs-1)-tmp_ndx)*c_off)), 
( (DxAnArea.bottom() - y_margin ) 
-y_unit*pTQ->TQ[TrkNdx}->dCnt{[r_curr]))); 
delete canvas()->popPen(Q); 


/fpTQ->TQ[TrkNdx]->cCnt[r_curr]; //store total number of chars 
/fpTQ->TQ[TrkNdx]->dCnt[r_curr] = dsum; 
/Af(numchrs>0){ 
//pTQ->TQ[TrkNdx]->csRatio[r_curr] = ((float)dsum/(float)numchrs); 
else { 
I plQ->TQ[TrkNdx]->csRatio[r_curr] = 0.0; 
I} endif 
Jelse{ //this is the last message 
/canvas()->textColor(zColor(255,0,0)); //red text if first message 
Hcanvas()->text(p, 
II 
}//endif 
canvas()->textColor(zColor(0,0,0)); //black text is default 


"Insufficient Data for Analysis”); 


}//endfor 


delete canvas()}->popFont(); 
/! zpb_end 
canvas(}->unlockQ; 

return |; 


| / Frame Member Functions - DatAn 


/ 


! Window Constructor 
NDatAn::WDatAn(zMDIAppFrame *w, const char *title) 
» ZMDIChildFrame(w,ZNEW ZSizer(zDialogUnit(3 10,155), 


zDialogUnit(100,100)),WS_CHILD|WS_THICKFRAME]|WS_SYSMENU|WS_MINIMIZEBOX|WS_CAPTION, title) { 
/! zpb_begin WDatAnConstructor2 

/1 zpb_end 

deleteOnClose(TRUE); 

backgroundColor(zColor(0,255,255)); 
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menu(ZNEW zMenu(this, zResid(IDM_DatAnDatAnMenu))); 
menu()->setCommand(this, (CommandProc)& WDatAn::cmdContoiRefresh, IDM_CONTROLREFRESH); 
pDatAnPane = ZNEW DatAnDatAnPane(this, ZNEW zGravSizer(ZGRAV_MIDDLE,0,sizer())); 
pDatAnPane->show(); 
sizer()->update(); 
// zpb_begin WDatAnConstructor 
pTQ->TQ[pTQ->newTrkAn]->AnWn = this; //this is a track analysis window 
/! zpb_end 
show(); 
} 


WDatAn::~WDatAn() { 
// zpb_begin WDatAnDestructor] 
p1Q->TQ[pDatAnPane->TrkNdx]->AnWn = NULL; 
// zpb_end 

} 


Hf 
// Menu Item Selection Handlers 
// 


int WDatAn::cmdControlRefresh(zCommandEvt* ev) { 
DSymRfsh* p=ZNEW DSymRfsh(this, zResId(LDD_SymRfsh)); 
p->modal(); 
if (p->completed()) { 
/! zpb_begin WDatAnControlRefresh 
/! zpb_end 
} else { 
// zpb_begin WDatAnControiRefreshCancel 
/! zpb_end 
} 
delete p; 
return 0; 


} 


// zpb_begin WDatAnMemberF unctions 
int WDatAn::rtrdrw() { 
zDrawEvt *dummyEv; 
pDatAnPane->draw(dummyEv); //the draw routine does not use this input param 
// zApp uses this as an event token for its 
// own dispatching 
return 0; 


}//end rtrdrwQ) 


// zpb_end 


// Pane Member Functions - jtidssldjpane 
jtidssldjpane::jtidssldjpane(z Window * w, zSizer *sz) : zPane(w, sz, WS_CHILD) { 


// zpb_begin pjtidssldjpaneConstructor1 
pjimg = new zBitmap(canvas(), "bground00.bmp”); 
// zpb_end 
show(); 
} 


int jtidssldjpane::size(zSizeEvt *ev) { 
setDirty(); 
/! zpb_begin jtidssldjpaneSize 
// zpb_end 
return zWindow::size(ev); 

} 


int jtidssldjpane::draw({zDrawEvt* ev) { 
canvas()->lock(); 
// zpb_begin jpaneDraw 
canvas()->bitmap(pjimg,zPoint(0,0), SRCCOPY); 
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// zpb_end 
canvas(}->unlock(); 
return 1; 


H 

// Frame Member Functions - judssld 

Ht 

// Window Constructor 

Wjtidssld:: Wjtidssld(zMDIAppFrame *w, const char *ttle) 

: ZMDIChildFrame(w,ZNEW ZSizer(zDialogUnit(0,0), zDialogUnit(517,412)),WS_CHILD, title) { 
// zpb_begin WjudssldConstructor2 
// zpb_end 
deleteOnClose(TRUE); 
menu(ZNEW zMenu(this, zResId(IDM_jtidssldjmenu))); 
menu()->setCommand(this, (CommandProc)& Wjtidssld::cmdInfoDInfo, IDM_INFODINFO), 
menu()->setCommand(this, (CommandProc)& Wjtidssl d::cmdInfoDIInfo, IDM_EINFODIINFO), 
pjpane = ZNEW jtidssldjpane(this, ZNEW zSizer(zDialogUnit(0,0),zDialogUnit(517,412))); 
pjpane->show{); 
// zpb_begin Wjtidss]dConstructor 
// zpo_end 
show(); 

} 


Wjtdssld::~WjtdssldQ { 
/f zpb_begin WjudssldDestructor] 
// zpb_end 

} 


If 
/f Menu Item Selection Handlers 
if 


int Wjtidssld::cmdInfoDinfo(zCommandEvt* ev) { 
DDDinfo* p=ZNEW DDDinfo(this, zZResId(IDD_DDinfo)); 
p->modal(); 
if (p->completed() { 
/f zpb_begin WjtidssldinfoDInfo 
/! zpo_end 
} else { 
// zpb_begin WjtidssldInfoDInfoCancel 
// zpb_end 
} 
delete p; 
return 0; 


} 


int Wytidssld::cmdInfoDIinfo(zCommandEvt* ev) { 
DDDInfo* p=ZNEW DDDDnfo( this, zResid(IDD_DDIInfo)); 
p->modal(); 
if (p->completed()) { 
// zpb_begin WjtidssldInfoDIinfo 
// zpb_end 
} else { 
/f zpb_begin WjtidssldInfoDHnfoCancel 
// zpo_end 
} 
delete p; 
return 0; 


} 


4 zpb_begin WjtidssidMemberF unctions 

int Wjtidssld::dinfo(DDDinfo *DDptr) { 
//DDDinfo *DDptr; 
DDpt->_mmHgt = pjpane->canvas()->mmHeight(); 
DDpt->_mm Wth = pjpane->canvas()->mm Width(); 
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DDptr->_pxHgt = pjpane->canvas()->pixHeight(); 
DDptr->_px Wth = pjpane->canvas()->pix Width(); 
DDptr->_pxPinX = pjpane->canvas()->pixPerInchX(); 
DDptr->_pxPinY = pjpane->canvas()->pixPerlnchY(); 
DDptr->_pfm = pjpane->canvas()->polyFillMode{); 
return 0; 


} 


int Wjtidssld::diinfo(DDDInfo *DDIptr) { 
/(DDDinfo *DDpt, 
zDisplaylnfo *zdisptr; 
zdisptr = ZNEW zDisplayInfo(pjpane->canvas()); 
int numclr; 
zdisptr->lockQ; 
numclr = zdisptr->colorResQ); 
DDIptr->_aspectX = zdisptr->aspectX{); 
DDIptr->_aspectXY = zdisptr->aspectX YQ); 
DDIptr->_aspectY = zdisptr->aspectY(); 
DDIptr->_colorPlanes = zdisptr->colorPlanes(); 
DDIptr->_colorRes = zdisptr->colorRes(); 
DD!Iptr->_numcolors = zdisptr->numColors(); 
DDIptr->_pixDepth = zdisptr->pixDepthQ); 
zdisptr->unlock(); 
//char tbuf[256}; 
//ostrstream tmpstr(tbuf, 256); 
/Iempstr << numclr << ends; 
//zString sbuf =" us 
//sbuf = tbuf; 


//canvas()->pushFont(new zFont("Helv",zPrPoint(i2,25,canvas()),900,ffDontCare)); 
/icanvas()-> text(5,5,sbuf); 
//delete canvas()->popF ont(); 


return 0; 


} 
/! zpb_end 


H/ 

// Dialog Member Functions - About 

If 

DAbout::DAbout(z Window *w,const zResId& rid) : ZFormDialog(w,rid) { 
// zpb_begin DAboutConstructor2 
/! zpb_end 
// zpb_begin DAboutConstructor 
/1 zpb_end 
center Window(this); // Center window on parent 
show(); 

} 


// zpb_begin DAboutMemberFunctions 
// zpb_end 


H/ 

/! Dialog Member Functions - MsgRfsh 

Hf 

DMsgRfsh::DMsgRfsh(zWindow *w,const zResId& rid) : ZFormDialog(w,rid) { 
/! zpb_begin DMsgRfshConstructor2 
// zpb_end 
pDRt = ZNEW zComboBoxStatic(this, ID_DRT, &_DRt); 
pDRt->add(zString(zResId(IDS_MSGRFSHDRT_1))); 
pDRt->add(zString(zResId(IDS_MSGRFSHDRT_2))); 
pDRt->add(zString(zResId(IDS_MSGRFSHDRT_3))); 
pDRt->add(zString(zResId(IDS_MSGRFSHDRT_4))); 
/! zpb_begin DMsgRfshConstructor 
WDx Win *tpt, 
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tpt = (WDxWin *) w; 
long tmpval; 
tmpval = (long)tptr->drwRt; 
CurRt(tmpval); 
pDRt->setToDe fault(); 
/! zpb_end 
center Window( this); /1 Center window on parent 
show(); 
} 


// zpb_begin DMsgRfshMemberFunctions 

int DMsgRfsh::CurRt(long CRt) { 
char tbuf[256]; 
ostrstream tmpstr(tbuf,strlen(tbuf)); 
tmpstr << dec << CRt; 
strcpy(_DRt,tbuf); 
return 0; 

Viend CurRtQ) 

/ zpb_end 


H 

4 Dialog Member Functions - MsgRate 

H 

DMsgRate::DMsgRate(z Window *w,const zResId& rid) : ZFormDialog(w,rid) { 
/! zpb_begin DMsgRateConstructor2 
/! zpb_end 
pMrt = ZNEW zComboBoxFull(this, ID_ MRT, &_Mrt); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_1}))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_2))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_3))); 
pMrt->add(zStnng(zResId(IDS_MSGRATEMRT_4))); 
pMrt->add(zString(zResId(DS_MSGRATEMRT_5))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_6))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_7))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_8))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_9))); 
pMrt->add(zString(zResId(IDS_MSGRATEMRT_10))); 
/! zpb_begin DMsgRateConstructor 
WDxWin *tptr; 
tpt = (WDxWin *) w; 
long tmpval; 
tmpval = (long)tptr->msgRt; 
CurRt(tmpval); 
pMrt->setToDefaultQ); 
// zpb_end 
center Window( this); // Center window on parent 
show(); 

} 


4 zpb_begin DMsgRateMemberFunctions 

int DMsgRate::CurRt(long CRt){ 
char tbuf[256]; 
ostrstream tmpstr(tbufstrlen(tbuf)); 
tmpstr << dec << CRt; 
strcpy(_Mrt,tbuf); 
return 0; 

iend CurRt() 

' zpb_end 


i 

# Dialog Member Functions - Tinfo 

H 

DTInfo::DTInfo(zWindow *w,const zResId& rid) : ZFormDialog(w,rid) { 


/! zpb_begin DTInfoConstructor2 
// following fragment shows how to create and delete this dialog 


/fref only: DTInfo* p=ZNEW DTinfo(this, zResid(IDD_Tinfo)); 
/Iref only: p->modal(); 


| 147 


//ref only: if (p->completed()) { 
// zpb_ Trk WinTrkPaneLButtonDown 

/Iref only: } 

//ref only: delete p; 
// zpb_end 
pETAIt = ZNEW zEditLine(this, ID ETALT, & ETAI/t, FLD NOTREQUIRED); 
pETTyp = ZNEW zEditLine(this, ID_ETTYP, &_ETTyp, FLD_NOTREQUIRED); 
pETNum = ZNEW zEditLine(this, ID ETNUM, & ETNum, FLD _NOTREQUIRED); 
pETSpd = ZNEW zEditLine(this, ID_ETSPD, & ETSpd, FLD_NOTREQUIRED); 
pETlocx = ZNEW zEditLine(this, ID ETLOCX, & ETlocx, FLD_NOTREQUIRED); 
pETlocy = ZNEW zEditLine(this, ID ETLOCY, &_ETlocy, FLD_NOTREQUIRED); 
pDType = ZNEW zComboBoxStatic(this, ID_ DTYPE, & DType); 
pDType->add(zString(zResId(IDS_TINFODTYPE_1))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_2))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_3))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_4))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_5))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_6))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_7))); 
pDType->add(zString(zResId(iDS_TINFODTYPE_8))); 
pDType->add(zString(zResId(IDS_TINFODTYPE_9))); 
// zpb_begin DTInfoConstructor 


int dnx = pTQ->DTindx; 
CrVi(_ ETAIt, pTQ->TQ[dnx]->altRaw); 
pETAIt->setToDefaultQ; 
strepy(_ETTyp, pTQ->TQ[dnx]->typSt); 
pETTyp->setToDefault(); 
strcpy(_ETNum, pfQ->TQ[dnx]->numSr); 
pETNum->setToDefaultQ); 
CrV1(_ETlocx, pTQ->TQ[dnx]->xRaw); 
pETlocx->setToDefault(); 
CrVi( ETlocy, pTQ->TQ[dnx]->yRaw); 
pETlocy->setToDefaultQ); 
CrV1(_ ETSpd, pTQ->TQ[dnx]->spRaw); 
pETSpd->setToDefaultQ; 
sircpy(_DType, pTQ->TQ[dnx]->dTypSt); 
pDType->setToDefault(); 
// zpb_end 
center Window( this); // Center window on parent 
show(); 

} 


// zpo_begin DTInfoMemberFunctions 
int DTInfo::CrVl(char *cvbuf, float cv) { 
char tbuf[256] =" ms 
ostrstream tmpstr(tbuf,strien(tbuf)); 
tmpstr << cv; 
strcpy(cvbuf,tbuf); 
return 0; 
Y/end CrV10 


int DTInfo::UpdAt(char *typstr){ 
int tmptype; 
tmptype = pDType->selection(); 
switch(tmptype) { 
case HOSTILE_AIR: 
strcpy(typstr, "HOSTILE AIRCRAFT"); 
break; 
case HOSTILE_SUB: 
strcpy(typstr, "HOSTILE SUBSURFACE"); 
break; 
case HOSTILE_SURFACE: 
strcpy(typstr, "HOSTILE SURFACE"); 
break; 
case UNKNOWN AIR: 
strcpy(typstr, "UNKNOWN AIRCRAFT"); 
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break; 

case UNKNOWN_ SUB: 
strcpy(typstr, "UNKNOWN SUBSURFACE"); 
break; 

case UNKNOWN_SURFACE: 
strcpy(typstr, "UNKNOWN SURFACE"); 
break; 

case FRIENDLY_AIR: 
strcpy(typstr, "FRIENDLY AIRCRAFT"); 
break; 

case FRIENDLY_SUB: 
strcpy(typstr, "FRIENDLY SUBSURFACE"), 
break; 

case FRIENDLY_SURFACE: 
strcpy(typstr, "FRIENDLY SURFACE"); 
break; 

}; /lend case statement 


//strcpy(typstr, "HOSTILE AIRCRAFT"); 
return tuptype; 

}//end CrV1Q 

41 zpb_end 


I 

// Dialog Member Functions - SymRfsh 

HW 

DSymRfsh::DSymRfsh(z Window *w,const zResId& rid) : ZFormDialog(w,rid) { 
/! zpb_begin DSymRfshConstructor2 
/! zpb_end 
pDRt = ZNEW zComboBoxStatic(this, ID DRT, &_DRt); 
pDRt->add(zString(zResId—IDS_SYMRFSHDRT_1))); 
pDRt->add(zString(zResId(IDS_SYMRFSHDRT_2))); 
pDRt->add(zString(zResId(IDS_SYMRFSHDRT_3))); 
pDRt->add(zString(zResId(IDS_SYMRFSHDRT_4))); 
// zpb_begin DSymRfshConstructor 
// zpb_end 
center Window‘ this); // Center window on parent 
show(); 

} 


/ zpb_begin DSymRfshMemberFunctions 
1 zpb_end 


I 

/f Dialog Member Functions - TrkRfsh 

It 

DIrkRfsh::DTrkRfsh(zWindow *w,const zZResId& rid) : ZFormDialog(w,nd) { 
// zpb_begin DTrkRfshConstructor2 
/! zpb_end 
pDRr = ZNEW zComboBoxStatic(this, ID_DRT, &_DRt); 
pDRt->add(zString(zResId(IDS_TRKRFSHDRT_1))); 
pDRt->add(zString(zResId(—IDS_TRKRFSHDRT_2))); 
pDRt->add(zString(zResId(IDS_TRKRFSHDRT_3))); 
pDRt->add(zString(zResId—IDS_TRKRFSHDRT_4))); 
// zpb_begin DTrkRfshConstructor 
WDx Win *tptr; 
tpt = (WDx Win *) w; 
long tmpval; 
tmpval = (long)tptr->drwRt; 
CurR1x(tmpval); 
pDRt->setToDefault(); 
/! zpb_end 
center Window‘ this); // Center window on parent 
show(); 

} 


M zpb_begin DIrkRfshMemberFunctions 
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int DTrkRfsh::CurRt(long CRt){ 


char tbuf[256]; 

ostrstream tmpstr(tbuf,strlen(tbuf)); 
tmpstr << dec << CR, 
strcpy(_DRt,tbuf); 

return 0; 


}//end CurRt() 


// zpb_end 


Hf 


/! Dialog Member Functions - TkSet 


/} 


DTkSet::DTkSet(zWindow *w,const zResId& rid) : ZFormDialog(w,nd) { 


} 


/! zpb_begin DTkSetConstructor2 

/! zpb_end 

_laMn = 0; 

_laMx = 0; 

_lgMn = 0; 

_IgMx = 0; 

plaMn = ZNEW 2FloatEdit(this, ID_ LAMN, &_laMn, "-#444H##.##", FLD_NOTREQUIRED); 
plaMx = ZNEW 2FloatEdit(this, ID LAMX, & _laMx, "~#HHHHH.##", FLD NOTREQUIRED); 
plgMn = ZNEW 2FloatEdit(this, ID_ LGMN, &_lgMn, "~+#HHHHH ##", FLD NOTREQUIRED); 
plgMx = ZNEW zFloatEdit(this, ID LGMX, &_lgM©Mx, "+#HHHHH #4", FLD _NOTREQUIRED); 
// zpb_begin DTkSetConstructor 

_laMn = pTQ->minlt; //this is for op area field 
_laMx = pTQ->maxlt; 

_lgMn = pTQ->minlg; 

_igMx = pTQ->maxlg; 

plaMn->setToDefault(); 

plaMx->setToDefault(); 

plgMn->setToDefaultQ); 

plgMx->setToDefault(); 

// zpb_end 

center Window( this); // Center window on parent 


showQ; 


// zpb_begin DTkSetMemberF unctions 


// zpb_end 


II 


// Dialog Member Functions - Rescale 


Hf 


DRescale::DRescale(zWindow *w,const zResId& rid) : ZFormDialog(w,rid) { 


// zpb_begin DRescaleConstructor2 

/! zpb_end 

_laMn = 0; 

_laMx = 0; 

_lgMn = 0; 

_lgMx = 0; 

plaMn = ZNEW 2FloatEdit(this, ID_LAMN, &_laMn, "~+44##HH}.##", FLD NOTREQUIRED); 
plaMx = ZNEW 2zFloatEdit(this, ID_LAMX, &_laMx, "~HHHHHHE##", FLD NOTREQUIRED); 
plgMn = ZNEW 2FloatEdit( this, ID_ LGMN, &_lgMn, "+#HHHHHE##", FLD NOTREQUIRED); 
plgMx = ZNEW zFloatEdit(this, ID_LGMX, &_lgMx, "~+#HHHHH ##", FLD NOTREQUIRED); 
// zpb_begin DRescaleConstructor 

pIQ->rescale(); 

_laMn = pTQ->minit; /Ithis is for op area field 
_laMx = pTQ->maxit; 

_lgMn = pTQ->minlg; 

_IgMx = pTQ->maxlg; 

plaMn->setToDefaultQ); 

plaMx->setToDefault0; 

plgMn->setToDefault(); 

plgMx->setToDefault(); 

/! zpb_end 

center Window( this); // Center window on parent 

show(); 
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} 


//zpb_begin DRescaleMemberF unctions 
/1 zpb_end 


Mt 
// Dialog Member Functions - FxdFmt 
HI 
DFxdFmt::DFxdFmt(zMDIAppFrame *w,const zResId& rid) : zMDIFormDialog(w,rid) { 
/! zpb_begin DFxdFmtConstructor2 
// zpb_end 
/! zpb_begin DFxdFmtConstructor 
/! zpb_end 
show(); 
} 


// zpb_begin DFxdFmtMemberF unctions 
// zpb_end 


il 
// Dialog Member Functions - DDinfo 
| 
DDDinfo::DDDinfo(zWindow *w,const zResId& rid) : zZFormDialog(w,rid) { 
/! zpb_begin DDDinfoConstructor2 
Wyjtidssld *wptr; 
wptr = ((Wjtidssid *) w); 
//_ Edit] = wptr->pjpane->canvas()->mmHeight(); 
int stat; 
Stat = wptr->dinfo(this); 
/! zpb_end 
_mmHgt = 0; 
_mmWth = 0; 
_pxHgt = 0; 
_pxWth = 0; 
_pxPinX = 0; 
_pxPinY = 0; 
_pfm = 0; 
pmmH et = ZNEW zintEdit(this, JD. MMHGT, &_mmHet, "##H#", FLD NOTREQUIRED); 
pmm Wth = ZNEW zintEdit(this, ID MMWTH, &_mmWth, "##4H4#", FLD _NOTREQUIRED); 
ppxHgt = ZNEW zintEdit(this, ID PXHGT, &_pxHegt, "HHH", FLD NOTREQUIRED); 
ppxWth = ZNEW zintEdit(this, ID PXWTH, & px Wth, "###H#", FLD_NOTREQUIRED); 
ppxPinX = ZNEW zintEdit(this, ID_PXPINX, & pxPinX, "#4", FLD_NOTREQUIRED); 
ppxPinY = ZNEW zintEdit(this, ID_PXPINY, &_pxPinY, "###H##}", FLD_NOTREQUIRED); 
ppfm = ZNEW zintEdit(this, ID_PFM, &_pfm, "##H4##", FLD_-NOTREQUIRED); 
/! zpb_begin DDDinfoConstructor 
// zpb_end 
center Window(this); // Center window on parent 
showQ); 
} 


4 zpb_begin DDDinfoMemberFunctions 
// zpb_end 


If 
/f Dialog Member Functions - DDIInfo 
I 
DDDIInfo::DDDiinfo(zWindow *w,const zResId& rid) : ZFormDialog(w,nd) { 
/! zpb_begin DDDIinfoConstructor2 
Wjtidssild *wptr; 
wptr = ((Wjtdssid *) w); 
//_ Edit] = wptr->pjpane->canvas(}->mmHeight(); 
int stat; 
Stat = wptr->diinfo(this); 
/! zpb_end 
_aspectX = 0; 
_aspectXY = 0; 
_aspectY = 0; 
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_colorPlanes = 0; 
_colorRes = 0; 
_numcolors = 0; 
_pixDepth = 0; 
paspectX = ZNEW zintEdit(this, ID_ ASPECTX, &_aspectX, "#####", FLD_NOTREQUIRED), 
paspectXY = ZNEW zintEdit(this, ID ASPECTXY, &_aspectXY, "#####", FLD_NOTREQUIRED); 
paspectY = ZNEW zintEdit(this, ID_ASPECTY, &_aspectY, "######", FLD_NOTREQUIRED); 
pcolorPlanes = ZNEW zIntEdit(this, ID COLORPLANES, &_colorPlanes, "###H##", FLD NOTREQUIRED); 
pcolorRes = ZNEW zlIntEdit(this, ID COLORRES, &_colorRes, "#####", FLD_NOTREQUIRED); 
pnumcolors = ZNEW zIntEdit(this, ID NUMCOLORS, &_numcolors, "#####", FLD_-NOTREQUIRED); 
ppixDepth = ZNEW zintEdit(this, ID_PLXDEPTH, &_pixDepth, "######", FLD_NOTREQUIRED); 
// zpb_begin DDDIInfoConstructor 
// zpb_end 
center Window(this); // Center window on parent 
showQ); 

} 


// zpb_begin DDDInfoMemberF unctions 
// zpb_end 


// 
// Simple function to center window within parent or screen 
i 
void center Window(zWindow *w, BOOL fOnParent) { 
zRect winRect, parentRect; 
int xWin, y Win; 


w->getExterior(winRect); 
zSystemInfo screen; 


if (fOnParent && w->parent()) { 
// retrieve parent rectangle 
w->parent()->getExterior(parentRect); 


// center within parent window 
xWin = parentRect.leftQ) + ((parentRect.width() - winRect.width(0)/2); 
y Win = parentRect.top() + ((parentRect.height() - winRect.height())/2); 


// adjust win x-location for screen size 
if (xWin+winRect.width( > screen.pix Width() ) 
x Win = screen.pix Width) - winRect.widthQ; 


// adjust win y-location for screen size 
if ( yWin+winRect.height() > screen.pixHeight( ) 
y Win = screen.pixHeightO) - winRect-height(); 
} 
else { 
// center within entire screen 
x Win = (screen.pix Width( - winRect.width(Q) / 2; 
y Win = (screen.pixHeight() - winRect.height() / 2; 
} 


// move window to new location 
w->move{ (xWin>0) ? x Win : 0, 
(yWin>0) ? yWin : 0, 
winRect.width(), 
winRect-height()); 
} 


// 

// Bitmap Pane Member Functions 

// 

zfBitmapPane::zfBitmapPane(zWindow* w, const zResId &id, zSizer* sz) 
:zPane(w, sz), theBitmap(id) { 
show(); 
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int zfBitmapPane::draw({zDrawEvt *e) { 
zRect r; 
getinterior(r); 
canvas()->lockQ); 


// Draw entire bitmap 


zBitmapDisplay *bd; 
bd = ZNEW zBitmapDisplay(&theBitmap); 
bd->lock(); 
bd->copyTo(canvas(), r.left0, r.top(, 
theBitmap.size().width(), theBitmap.size().height(), 0, 0); 
bd->setBitmap(0); 
bd->unlockQ; 
delete bd; 
canvas()->unlock(); 
return TRUE; 
} 


// zpb_begin AppUserCode 
// zpb_end 


Hf 

/f Application Entry Point 

Mt 

void zApp::mainQ) { 
initIntPackQ; 
// zpb_begin AppMain 
/! zpo_end 
WMain* p=ZNEW WMain(zString(zResId(IDS_MAIN))); 
/! zpb_begin AppMain2 
// zpb_end 
go0); 
delete p; 


/! zpb_begin AppMain3 
// zpb_end 
} 


[PPESSSSSSSSSSSSSSSS SSS SSESSSSSSSSSSSS SSS SSS SS SSSHE SSS SSS SSE SSE SESS ESSE F / 


#include “output.h" 
/#include "..\include\output.h* 
#include <time.h> 


fF FSSSSSS SSS SES SESSSSSSSSSSSSSSSSSS ESS SSSSHE SSS SESS SSS 
SSESSCSCSSSESSSES SSE SESSES SSSSSSSSSSSSSSHSESHSESSHSESSSS SESS SF / 


int InitOutput(HINSTANCE hinstance) { 
WNDCLASS wndelass: 


Hcheck to see if the class is already registered 
iff GetClassInfo(hinstance,"Output" & wndclass)) 
retum TRUE; 


/fregister the class 
wndclass.style 
wndclass.ipfn WndProc 


=CS_HREDRAW|CS VREDRAW |CS_DBLCLKS; 
= Output WndProc; 


wndclass.cbClsExtra 
wndclass.cbWndExtra 
wndclass.hinstance 

wndclass.hIcon 

wndclass.hCursor 
wndclass.hbrBackground 
wndclass.IpszMenuName = NULL; 
wndclass.ipszClassName 


=10; 
=10; 
= hinstance ; 
= Loadicon(NULL, ID1_APPLICATION) ; 
= LoadCursor(NULL, IDC_ARROW); 
= NULL; 


= "Output"; 
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} 


RegisterClass(& wndclass); 

//make sure the class is registered 
if(GetClassInfo(hInstance,"Output",& wndclass)) 
return TRUE; 


return FALSE; 


[FFSSSSSSSSSSSSSESSSSSSSSESSSSESSSSSS SSE SES SSE SE SESS SESS 


Output WndProc 


Purpose 
Window Message Proc 


SHESSSSES SSS SSSSSSS SSH SSHSSTESSSSS SESS SSK SESSES ESS SS S/ 


long far pascal OutputWndProc(HWND hwnd,UINT message, WPARAM wParam,LPARAM I|Param){ 


int LXLY; 

int oldnumlines; 
int position; 
int len; 

int update; 
char * Cc; 

SIZE size; 
RECT rect; 
HDC hdc; 
OUTPUT * Op; 
OUTPUTITEM * itemlist; 


[[FFFFFSSESSSSSSESSSSSS SSS SES SSSSSSSSSHSSE SESE SHEESH ESET SE 


/ff this is the first message then setup the data strucure 
if(message == WM_NCCREATE){ 


//create a new output structure and store it 
op = new OUTPUT; 
Set WindowLong(hwnd,0,(long)op); 


//set up the inital variable values 


op->font = NULL; 
op->numlines = 0; 
op->numscreenlines = 0; 
op->numitemsloaded = 0; 
op->viewoffset = 0; 
op->scrollrange = 0; 
op->margin =2; 
op->textcolor = GetSysColoy¥COLOR_WINDOWTEXT); 
op->backcolor = GetSysColot{COLOR_WINDOW); 
op->textalign = 1; Nef 
op->enablelog = FALSE; 
op->datedlog = FALSE; 
op->filename = NULL; 
op->fptr = NULL; 

op->historysize = 0; 
op->items = NULL; 
op->lineheight = 0; 
op->lastrowclicked =-1; 
op->hscrollrange = 0; 
op->maxlinewidth = 0; 
op->hviewoffset =0; 

op->stamptype =0; 


} 
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[fF FFSSSSSSSSSESS SESSA SKSSKSKSSS SSS SHAS SSS EKESEKE SEES 


//get the pointer to the data structure 

else { 

op = (OUTPUT *)GetWindowLong(hwnd,0); 
} 


[fF FFSSSSSSSSSTSS SSS SSS SSSSSSSSS SST SSKSSSTSKTSK SK SSS KS SSSS 


/Af the datastructure is NULL then just use the default message handling 
if(op==NULL) { 

return DefWindowProc(hwnd,message,wParam,!Param); 

} 


[fF EFESSSSSSSSSSSSSS SSS SSS SSSA SAS SSSSST SESS SERS SEES S 


/[***** process messages ***** 
switch(message) { 


[/fEFSSSSESTESSSSSESSSSSSS TTS STSSE SSS SSSSESSSTSETTSSSSSETS SSS 

case WM_CREATE: { 
SendMessage(hwnd,WM_SIZE,0,0); 
return 1; s 


[fPPPFSSSSSAASSSSSESSESSSSSSSSSS SSS SS SSSS SSK SASSESSSASSS 


// if destroying then delete all data 
case WM_NCDESTROY:{ 


if(op->items != NULL) { 
for( t= 0 ; t < op->numlines ; t++ ){ 
iffop->items([t].string != NULL) 
delete[] op->items[t].string; 


delete[] op->items; 


} 


iffop->filename != NULL) 
delete[] op->filename; 


if(op->fptr != NULL) 
fclose(op->fptr); 


delete op; 
op = NULL; 


SetWindowLong(hwnd,0,(long)op); 
return 1; 


} 


/{PPPRSESESEESSSS TERESA ASESESSSSESS ELSES AAESSSAASS SES SS 


// if sizing then get the new number of lines 
/{ then allocate or delete memory for the new number of lines 
case WM_SIZE:{ 


//get the height of a character 

hde = GetDC(hwnd); 

if(op->font '=NULL) 
SelectObject(hdc,op->font); 

GetTextExtentPoint(hdce,"X", 1 ,&size); 

op->lineheight = size.cy; 

ReleaseDC(hwnd,hdc); 


GetClientRect(hwnd,&op->clientrect); 


/{get the number of total rows and the number that can be displayed 
oldnumlines = op->numlines; //old num rows 
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rows 


rows 


} 


op->numlines = (op->clientrect.bottom / op->lineheight) +1 + op->htstorysize; //new num 


if(op->numlines < op->historysize) //double check 
op->numlines = op->historysize; 
op->numscreenlines = (op->clientrect.bottom / op->lineheight) +1; //number of visible 


if(op->numscreenlines < 1) //double check 
op->numlines = 1; 


//adjust the view offset 
if(op->numlines <= op->numscreenlines) 
op->viewoffset =0; 


//realloc the mem 
itemlist = new OUTPUTITEM[op->numlines]; 


//copy the info from the old list to the new one 


for(t=0; t < op->numlines;t++) { 
if{t < oldnumlines) { 
itemlist[t].string = op->items[t].string; 
itemlist{t].color | =op->items[t].color; 


itemlist(t].align | = op->ttems[t].align; 
itemlist{t].width =‘op->items[t].width; 


} 
else { 
itemlist[t].string = NULL; 
itemlist[t].width = 0; 
} 
} 
/fremove the old info 


for(t=op->numlines;t<oldnumlines;t++) { 
if{(op->items[t].string != NULL) 
delete[] op->items[t].string; 
op->items[t].width = 0; 
} 
delete[] op->items; 


/freset the pointer 

op->items = itemlist; 

//adjust the number of loaded items 

if{op->numitemsloaded > op->numlines) 
op->numitemsloaded = op->numlines; 


//adjust the scrollbars 
AdjustScrollBars(hwnd,op); 


return 1; 


/[PPFFSSSSESSSSESSSSS SSS SESSA SSESSE SESH ASESSE ES ESEESE TEESE 


// paint the window 
case WM_PAINT:{ 


//set up the device context 

hdc = GetDC(hwnd); 

if{op->font !=NULL) 
SelectObject(hdc,op->font); 

SetBkColor(hdc,op->backcolor); 


//get the client area 
GetClientRect(hwnd,&rect); 
y= rect.bottom; 


if( op->numitemsloaded >= op->numscreenlines) { 
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x= op->viewoffset/op->lineheight; 
y = op->viewofiset“op->lineheight; 
for( t = rect.bottomty ; t > 0 ; t= op->lineheight) { 


//set up the rectangle 

rect.bottom = t; 

rect.top = rect.bottom - op->lineheight; 

//setup the alignment 

if(op->items[x].align = 1 ){ /Neft 


SetTextAlign(hdc,TA_LEFT); 
position = rect.left + op->margin; 

} 

else if(op->items[x].align ==2) { /icenter 
SetTextAlign(hdc,TA_CENTER); 
position = (rect.right - rect.left)/2; 

} 

else if{op->items[x].align ==3) { /right 
SetTextAlign(hdc,TA_RIGHT); 
position = rect.right - op->margin; 

} 

//set the text color 

SetTextColor(hdc,op->items[x].color); 

//draw the line ; 

ExtTextOut(hdc,position - op->hviewoffset,rect.top,ETO OPAQUE,&rect, 
op->items[x].string,|strlen(op->items[ x].string), NULL); 


XT 
} 
} 
else { 
for(t = op->numitemsloaded -1;t >=0;t--) { 
//set up the rect 
rect.bottom = rect.top + op->lineheight; 
//setup the alignment 
if(op->items|[t].align ==1){ /Neft 


SetTextAlign(hdc,TA_LEFT); 
position = rect.left + op->margin; 
} 
else iffop->items|[t].align ==2){ /Icenter 
SetTextAlign(hdc,TA_CENTER); 
position = (rect.right - rect.left)/2; 


} 

else if{op->items[t).align ==3){ /right 
SetTextAlign(hdc, TA_RIGHT); 
position = rectright - op->margin; 

} 

//set the text color 

SetTextColor(hdc,op->items[t].color); 

//draw the text 

ExtTextOut(hdc,position- op->hviewoffset- op- 

>hviewoffsetrect.top,ETO_OPAQUE,&rect, 

op->items[t).string,lstrlen(op->items[t].string), NULL); 


rect.top = rect.bottom; 
} 
rect.bottom = y; 
ExtTextOut(hdc,rect.leftrect.top ETO _OPAQUE,&rect,"",0,NULL); 
} 


ReleaseDC(hwnd,hdc); 
ValidateRect(hwnd,NULL); 
return 1; 


} 


[APPR eee eee SESS LELESERESESESESE RES SESS SESS SSE SSE SES 


/Imouse clicks 
case WM_LBUTTONDBLCLK: 
case WM_RBUTTONDOWN: 
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case WM_LBUTTONDOWN: { 


} 


//find the row that was clicked in 

if{ op->numitemsloaded >= op->numscreenlines) { 
y = op->clientrect.bottom - (short)HIWORD(iParam) + op->viewoffset; 
op->lastrowclicked = y / op->lineheight; 

} 

else { 
y = (short)HIWORD(iParam); 
op->lastrowclicked = op->numitemsloaded - (y / op->lineheight) -1; 

} 

if(message —= WM_LBUTTONDOWN) 
SendNotifyMessage(hwnd,OPN_LCLICKED); 

else if(message == WM_RBUTTONDOWN) 
SendNotifyMessage(hwnd,OPN_RCLICKED); 

else if(message == WM_LBUTTONDBLCLK) 
SendNotifyMessage(hwnd,OPN_DCLICKED); 

return 0; 


[PPE ESESSESACEES EE TSEAECE SEES ASSES INVA TSE SH TSS 7 ee 


//set the new font then recalc the number of lines 


case WM_SETFONT:{ 


op->font = (HFONT)wParam; 
SendMessage(hwnd,WM_SIZE,0,0); 
return |; 


[LR TTT ECCS STIS OSESESS SESSA S SETAE TT ESP SECS SESE VINO ee ee 


//vertical scroll bar 
case WM_VSCROLL:{ 


y = op->viewoftset; 


switch(LOWORD(wParam)) { 
case SB_BOTTOM a 
op->viewoffset =0; 
break; 


} 

case SB_LINEDOWN:{ 
op->viewoffset —op->lineheight; 
break; 


} 

case SB_LINEUP:{ 
op->viewoffset +=op->lineheight; 
break; 


} 

case SB_PAGEDOWN: { 
op->viewoffset = op->clientrect.bottom; 
break; 


} 

case SB_PAGEUP:{ 
op->viewoffset += op->clientrect.bottom; 
break; 


} 
case SB_THUMBTRACK: 
case SB_THUMBPOSITION: { 
#ifdef WIN32 
op->viewoffset = op->scrollrange - HIWORD(wParam); 
#else 
op->viewoffset = op->scrollrange - LOWORD(iParam); 
#endif 
break; 


} 
case SB_TOP:{ 


op->viewoftfset = op->scrollrange; 
break; 
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//check the range 
if(op->viewoffset < 0) 
op->viewoffset = 0; 
iffop->viewoffset > op->scrollrange) 
op->viewoffset = op->scrollrange; 
/icheck for change in position 
if{y != op->viewoffset) { 
/fupdate 
SetScrollPos(hwnd,SB_VERT,op->scrollrange - op->viewoffset, TRUE); 
InvalidateRect(hwnd,NULL,TRUE); 
} 
return 0; 


[fF SSETASSSSSS SSESASSSSS ESS SESSVS LS LEST SSSSSSLAKAREST ETERS S 


/Wertical scroll bar 
case WM_HSCROLL: { 


x = op->hviewoffset; 


switch(LOWORD(wParam)) { 
case SB_BOTTOM :{ 
op->hviewoffset = op->scrollrange;; 
break; : 


} 

case SB_LINEDOWN: { 
op->hviewoffset += 10; 
break; 


} 

case SB_LINEUP:{ 
op->hviewoffset = 10; 
break; 


} 

case SB_PAGEDOWN: { 
op->hviewoffset += op->clientrect.nght; 
break; 


} 

case SB_PAGEUP:{ 
op->hviewofiset = op->clientrect.right; 
break; 


} 
case SB_THUMBPOSITION: 
case SB_THUMBTRACK:{ 
#ifdef WIN32 
op->hviewoffset = HIWORD(wParam); 
#else 
op->hviewoffset = LOWORD(1Param); 
#endif 
break; 


} 

case SB_TOP:{ 
op->hviewoffset = 0; 
break; 

} 


} 
/icheck the range 


if(op->hviewoftfset <0) 
op->hviewoftfset =0; 
if(op->hviewoffset > op->hscrollrange) 
op->hviewoffset = op->hscrolirange; 


//check for change in position 

if{x != op->hviewoffset) { 
/fupdate 
SetScrollPos(hwnd,SB_HORZ,op->hviewoffset, TRUE); 
InvalidateRect(hwnd,NULL, TRUE); 

} 

return 0; 
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} 


[[RPESASAATSSTEESA SSS TESS TEESE 8 ee ee 


//add a new line of text 


case OP_ADDLINE: { 


//params 
Cc = (char *)]/Param; 
position = wParam; 
if(position <0) 
position = 0; 


/Icheck to see if the line being remove was the widest 

/Af so then find the new widest item 

X = op->numlines - 1; 

if(op->items[x].width = op->maxlinewidth) { 
op->maxlinewidth =0; 
op->items[x]. width =0; 
for(t=0;t< op->numlines;t++) { 

if(op->items[t].width > op->maxlinewidth) 
op->maxlinewidth = op->items(t].width; 

} 


} e 
//remove the last string - at the very end of the list 


if(op->items[x].string !=NULL) 
delete[] op->items[x].string; 


//move all the strings color and alignment info above the 

//specified entry position 

for(t=(op->numlines-1);t>position;t—) { 
op->items([t].string = op->items(t-1].string; 
op->items|[t].color = op->items|t-1 ].color; 
op->items[t].align = op->items[t-1].align; 
op->items[t].width = op->items|[t-1].width; 

} 


//add the new string color and alignment info 
if(c == NULL) 

c =. 
//copy the string and expand tabs 
op->items[position].string = ExpandTabs(c ); 


op->items[position].color = op->textcolor; 
op->items[position].align = op->textalign; 


//get the width of the string 

hde = GetDC(hwnd); 

if(op->font !=NULL) 
SelectObject(hdc,op->font); 

GetTextExtentPoint(hdc,c,Istrlen(c),&size); 

op->items[position].width =size.cx; 

ReleaseDC(hwnd._hdc); 


//check to see if this is a max width 
if(op->maxlinewidth < size.cx ) 
op->maxlinewidth = size.cx; 


//adjust the number of items loaded 

op->numitemsloaded++; 

if(op->numitemsloaded > op->numlines) 
op->numitemsloaded = op->numlines; 


/Af logging then add the line to the log 


if(op->enablelog) { 
WriteToLog(op,&op->items[position]); 
} 
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//adjust the scrollbars 
if(op->viewoffset > 0) 

op->viewoffset += op->lineheight; 
AdjustScrollBars(hwnd,op); 


//re-draw 
InvalidateRect(hwnd,NULL, TRUE); 
return 1; 


[[¥EFEESSSESSESE SEES ESSE SKE TESESE SESE EESEESESEEESEEESEEEEEESE 


case OP_ADDSTAMPEDLINE: { 
len = Istrlen((LPSTR)IParam) +30; 
¢ = new char{len]; 


GetTimeDateStamp(c,20,op->stamptype); 

istreat(c," "); 

Istrcat(c,(LPSTR)I|Param); 
SendMessage(hwnd,OP_ADDLINE,wParam,(LPARAM)c); 
delete[] c; 


return 1; 


[[EFFSSSSSESSESSSSE SES SSS SESS SSSSSTSSSSSKSSSTTSESESTSEKELETEKES SS 


case OP_SETMARGINS: { 
/icheck for a valid range 
if((int)wParam >=0 && wParam <1000){ 
op->margin = wParam; 
/fre-draw 
InvalidateRect(hwnd,NULL, TRUE); 
retum TRUE; 


} 
return FALSE; 
} 


ie SPT SS ESS SSS SASS SSS TEST SSETESSESTE SSS ETTESESE SS SOVASS 


case OP_SETTEXTALIGN: { 
//check for a valid range 
if(wParam >0 && wParam <4){ 
op->textalign = wParam; 
/fre-draw 
InvalidateRect(hwnd,NULL,TRUE); 
return TRUE; 


else { 
op->textalign = 1; 


} 
return FALSE; 
Ne ei cc cv nsauvicessse000Paganacet tage 
case OP_CLEAR:{ 
//delete all strings 
iffop->items != NULL) { 
for(t=0;t<op->numlines;t++){ 
if(op->items[t].string!=NULL) { 
delete[] op->items[t}.string; 
op->items|[t].string = NULL; 


} 
op->items|[t].width = 0; 
} 

j 

op->numitemsloaded =0; 

op->viewoffset =0; 
SetScrollRange(hwnd,SB_VERT,0,0, TRUE); 
op->maxlinewidth =0; 

op->hviewoffset =0; 


SetScrollRange(hwnd,SB_HORZ,0,0, TRUE); 
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//re-draw 
InvalidateRect(hwnd,NULL, TRUE); 
return 1; 


J [ESTES EALESES FARE SEREC SES ESAS STOO OTT ee ee eee ee eee 


case OP_SETTEXTCOLOR: { 


//set the color 

op->textcolor = (COLORREF)|Param; 
//re-draw 
InvalidateRect(hwnd,NULL,TRUE); 
return 1; 


[[EAETESETAECESE STE SESE SESS CONES Oe ee eee 


case OP_SETBACKCOLOR:{ 


} 


//set the color 

op->backcolor = (COLORREF)iParam; 
/Ire-draw 
InvalidateRect(hwnd,NULL, TRUE); 
return 1; 


[[EFPEESECECEEESSSE SES STEERS SE SEVES SSE SVSSAETAE CESSES SEAS 


case OP_SETLOGNAME: { 


if(op->filename != NULL) 
delete[Jop->filename; 


op->filename = new char{lstrlen((LPCSTR)IParam}+ 1]; 
Istrepy(op->filename,(LPCSTR)IParam); 


/Af logging is enabled then open the log 


OpenLogFile(op); 
return 1; 


[[FEEEESERESESESEREEEEEEE REE EEEEE AE HESS RHERAEKE EEE REEEES 


case OP_ENABLELOG:{ 


} 


if(wParam 0) 

op->enablelog = FALSE; 
else { 

op->enablelog = TRUE; 

/Af logging is enabled then open the log 
; OpenLogFile(op); 


return op->enablelog; 


/[[F EFF eHEAEEESEERE KEARSE AKERS EERE ERE HERE HESESSEESSEEES 


case OP_ DATEDLOGGING: { 


if(wParam ==0) 

op->datedlog = FALSE; 
else { 

op->datedlog = TRUE; 

/Af logging is enabled then open the log 
OpenLogFile(op); 


return op->datedlog; 


[[¥ TEESE SHEASHE KE EEEESATHSE ESSE SRE EEA SERA RERE SEEKERS EE 


case OP_HISTORYSIZE: { 


//set the history size 

op->historysize = wParam; 

if(op->historysize < 0) 
op->historysize =0; 

if(op->historysize > 1000) 
op->historysize = 1000; 

//call WM_SIZE to readjust 

SendMessage(hwnd,WM_SIZE,0,0); 

return op->historysize; 
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//¥ OE O884O 8405584 OS EEE ESEEEEEEESEEEEEOHEEEERE REESE 


case OP_GETROWCLICKED: { 
return op->lastrowclicked; 


//PPSSSSSSSSSSSSESSS SSS SH SS SELSEES EEEEHEEEEEEEEEEEEEEEEEE 


case OP_GETTEXTLENGTH:{ 
if((int)wParam >=0 && (int)wParam < op->numscreenlines) { 
return Istrlen(op->items{wParam].string); 
} 


else { 
return 0; 


} 


/fPPSSSSSSSSSSSSSSSSSESSSS SS ESSE SESE SHEE EESE ESE EEEEEESEEE 


case OP_GETTEXT: { 
if((int)wParam >=0 && (int)wParam < op->numscreenlines) { 
Istrepy((LPSTR)IParam,op->items[wParam].string); 
return TRUE; 


} 
return FALSE; 


[/fPSSSSSSSSSSSSSSSSSSSSSSSSSS SESS SSS SSS SESA SHELL ERE SESE 


case OP_DELETELINE:{ : 
if((int)wParam >=0 && (int)wParam < op->numitemsloaded) { 


/icheck to see if the line being removed was the widest 
/Af so then find the new widest item 
if(op->items[wParam].width == op->maxlinewidth) { 

op->maxlinewidth =0; 

op->items[wParam].width =0; 

for(t=0;t< op->numlines;t++) { 

if(op->items([t].width > op->maxlinewidth) 
op->maxlinewidth = op->items[t}.width; 


} 


//delete the string 
if(op->items[wParam].string != NULL) 
delete[] op->items[wParam].string; 


//shift items down one 

for(t=wParam ; t< (op->numitemsloaded -1); t++){ 
op->items[t].string = op->items([t+ 1 ].string; 
op->items{t].color = op->items[t+ 1 }.color; 
op->items[t].align = op->items(t+1 J.align; 
op->items[t].width = op->items[t+1].width; 

} 

op->items[t].string = NULL; 

op->items[t].width = 0; 


op->numitemsloaded —; 


//adjust the scrollbars 
AdjustScrollBars(hwnd,op); 


/lre-draw 
InvalidateRect(hwnd,NULL, TRUE); 


return TRUE; 
} 
return FALSE; 


/[PPRRRSEERS SSE SE TEESE ESSE SESE LESSERSSESSESESES ES SES 


case OP_UPDATELINE: { 


/icheck the range 
if((int)wParam <0 jj (int)wParam >= op->numitemsloaded) { 
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return FALSE; 
} 


//get the params 
Cc = (char *)lParam; 
position = wParam; 


/Icheck to see if the line being updated was the widest 
/fif so then find the new widest item 
if(op->items[position].width == op->maxlinewidth) 


update = TRUE; 
else 

update = FALSE; 
//add in extra lines if ness. 


if(position >= op->numitemsloaded){ 
for(t = op->numitemsloaded; t<position;t++) { 
op->items{t].string = new char{2]; 
istrcpy(op->items(t].string,”"); 
op->items[t].color = op->textcolor; 
op->items{t].align = op->textalign; 
op->items[t].width = 0; 
} . 
op->numitemsloaded = position +1; 
} 


/hapdate the specified line 
if{ op->items[position].string '= NULL) 

delete[] op->items[position].string; 
op->items[position].string = new char{Istrlen(c)}+1]; 
Istrepy(op->items[position].string,c); 
op->items[position].color = op->textcolor; 
op->items[position].align = op->textalign; 
op->items[position].width = 0; 


/Af update is true then find the widest line 
if(update) { 
op->maxlinewidth =0; 
op->items[wParam].width =0; 
for(t=0;t< op->numlines;t++) { 
if(op->items[t].width > op->maxlinewidth) 
op->maxlinewidth = op->items{t].width; 


} 


//re-draw 
InvalidateRect(hwnd,NULL, TRUE); 


return TRUE; 


[[P PPPS SSeS SS SSH SSE SS SEH SSE SE SSE ES SEES SES SS 


case OP_STAMPSTYLE: { 


if(wParam == FALSE) 
op->stamptype = FALSE; 

else , 

op->stamptype = TRUE; 

return op->stamptype; 


[/fPFFSSSSSSS SSS SS SHES SSES SESE SK SES ES SHKSHESHEE ESET SHEE SS 


case OP_GETNUMLINES: { 
return op->numitemsloaded; 


[/{PSSESSSSSSSHS SESS SSH SSH ESSE SKS SHAH EH EEA KSSH ESE SEES 


case OP_UPDATESTAMPEDLINE: { 
len = Istrlen((LPSTR)IParam) +30; 
c = new char{len]; 
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GetTimeDateStamp(c,20,op->stamptype); 

istreat(c,” "); 

istrcat(c,(LPSTR)iParam); 
SendMessage(hwnd,OP_UPDATELINE,wParam,(LPARAM)<c); 
delete[] c; 


return 1; 


return Def WindowProc(hwnd,message,wParam,!Param); 


Se + 7 + SS ST PSSST SS SS SS PES TES LE SESS ET ES ETE SE SF 
Bee eESSSSSESCSSSSKLSSSSSS SSS SSS ASSES ASL SSSSESA SSS D / 


int OpenLogFile(OUTPUT * op){ 


char *path; 
int extension,len; 
char date[10]; 


/Icheck to see if logging is enabled 
if(op->enablelog == FALSE) { 
return FALSE; 

} 


//alloc a string for the filepath 
path = new char{Istrien(op->filename)+ 10); 


/Iclose old log file if open 
' if{op->fptr != NULL) 
fclose(op->fptr); 


//get the logfile name if dated logfiles are used 
if{op->datedlog) { 


//get the date 
GetDateString(op,date,10); 


//find where the filename extension is 
len = Istrien(op->filename); 
for(extension =0;extension < len ;extension++) { 
if{op->filename[extension]=—".') 
break; 


if(extension != len) { 
op->filename[extension]=0; 
wsprintf(path,"%s%s.%s",op-> filename,date,&op->filename[extensiont 1 }); 
op->filename[extension]=".’; 


else { 
wsprintf(path,"%s%s" op->filename,date); 
} 

} 

else { 

Istrcpy(path,op-> filename); 

} 

//fopen the log file 
op->fptr = fopen(path,"a+"); 
delete[] path; 


if(op->fptr != NULL) 
return TRUE; 


return FALSE; 
} 
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[PERSE SSEHEEESESESESERESEHSEESSEES ESOS SSESESS SSS 
SHEEEKSESESEKSESTSHSSSSEKSEKREHSESHEESSSEEEE SESE EESES ES / 


int WriteToLog(OUTPUT *op,OUTPUTITEM *item){ 


time_t tt; 
struct tm * systime; 


/Icheck the date if datedlogging 

if(op->datedlog) { 

//get the tme/date 

tt = time(NULL); 

systime = localtime(&tt); 

//store the current date 

if(op->logday != systime->tm_mday || op->logmon != systime->tm_mon || 
op->logyear != systime->tm_year){ 

OpenLogFile(op), 

} 

} 

//write the line 
fwrite(item->string,sizeof{char),strlen(item->string),op->fptr); 
fwrite("\n",sizeof(char), 1,op->fptr); 


return TRUE; 


[PSSESSSSSSSSEKSSSSSSSSKSSSEKSESHKSLSE SE SESSSES SSE 
SEHSSEHHHTESASSSSSSKSEKSESEKKEKEKEKEKEKEKEK ESE ES / 


int GetDateString(OUTPUT *op,LPSTR string, int len) { 


time t t 
struct tm *systime; 


if(len < 7) 
return FALSE; 


//get the time/date 
t=time(NULL); 
systime = localtime(&t); 


//store the current date 
op->logday = systime->tm_mday; 
op->logmon = systime->tm_mon; 
op->logyear= systime->tm_year; 


wsprintf(string,"%2.2d%2.2d%2.2d",systime->tm_year,systime->tm_mon+l, 
systime->tm_mday); 


return TRUE; 
} 


[FESS ESSESRSEEESESESE SESE EEE ESSER ESEEESKES SEE ESTEE 
type 0 - date + time 
1 - time only 
PETE T TAT T TEESE SSS OTE SSS ASA ESSE ASSESS SEES 


int GetTimeDateStamp(LPSTR string, int len,int type) { 


time _t t 
struct tm *systime; 


if(len < 18) 
retum FALSE; 


//get the time/date 
t=time(NULL); 
systime = localtime(&t); 


if(type 0) { 
wsprintf(string,"%2.2d/%2.2d/%2.2d %2.2d:%2.2d:%2.2d", 
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systime->tm_mday,systime->tm_mon+l,systime->tm_year, 
systime->tm_hour,systime->tm_min,systime->tm_sec); 

} 

else if{type =1){ 

wsprintf{(string,"%2.2d:%2.2d:%2.2d", 
systime->tm_hour,systime->tm_min,systime->tm_sec); 

} 

return TRUE; 


} 


ee POSS CSSS SSS S ES SESS SESE SESS SESS SS SSS 
SSSSHSSESSSSSTSE SS SSS SESS SESS SS SES SSS SS SES SSS SESS / 


long SendNotifyMessage(HWND hwnd. int message){ 


#ifdef _WIN32 

long ID = GetWindowLong(hwnd,GWL ID); 

return SendMessage(GetParent(hwnd), WM_COMMAND,MAKELPARAM(ID, message),(LPARAM)hwnd); 
#else 

WORD ID = GetWindowWord(hwnd,GWW_ID); 

return SendMessage(GetParent(hwnd), WM_COMMAND,ID,MAKELPARAM(hwnd.message)); 

#endif 


a + Se SSSESSSETSES SSS SESS SSS SESS SESS SS SESS SSS SESS SE 
SESESE SES SSS SESS SSS SS SESS SS SS SSS SSS S SESS SSS SS SH / 


int AdjustScroliBarsS(HWND hwnd,OUTPUT *op){ 


/fadjust the vertical scroll bar 
if((op->numitemsloaded * op->lineheight) > op->clientrect.bottom ){ 
op->scrollrange = (op->numitemsloaded * op->lineheight) - op->clientrect.bottom - 1; 
if(op->viewoffset > op->scrollrange) 

op->viewoffset = op->scrollrange; 
SetScrollRange(hwnd,SB_VERT,0,op->scrollrange,FALSE); 
SetScrollPos(hwnd,SB_VERT,op->scrolirange - op->viewoffset, TRUE); 
} 
else { 
SetScrollRange(hwnd,SB_VERT,0,0, TRUE); 
op->viewofiset = 0; 
} 


/fadjust the horizontal scrollbar 
if{((op->maxlinewidth + op->margin*2) > op->clientrect.night){ 
op->hscrolirange = (op->maxlinewidth + op->margin*2) - op->clientrect.night, 
if(op->hviewoffset > op->hscrollrange) 
op->hviewoffset = op->hscrolirange; 
SetScrollRange(hwnd,SB_HORZ,0,op->hscrollrange, TRUE); 
SetScrollPos(hwnd,SB_HORZ,op->hviewoftset, PRUE); 
} 
else{ 
SetScrollRange(hwnd,SB_HORZ,0,0, TRUE); 
op->hviewoffset =0; 
} 
retum TRUE; 
j 


feseseeese SETKSSSSSSSHESSSSSSESSESSSSSSSSESSCSSHVSVS 
STOCSSSSSASSHSSSASSSHHSKSSSE SS SSSTS STS SSSSSVSESSES/ 


LPSTR ExpandTabs(LPSTR in){ 


int t; 
int num =0; 
int len = Istrlen(in); 
int pos; 
LPSTR out; 


for(t=0;t<len;t++) { 


if(in[t]==9) 
numt++; 
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} 
num = (num*5)tlen; 


out = new char{num+] }; 


pos =0; 

for(t=0;t<len;t++) { 

if{in[t]==9) { 
out[pos]=32; 
pos++; 
out[pos]=32; 
pos++; 
out{[pos]=32; 
pos++; 
out[pos]=32; 
post++; 
out[pos]=32; 
post+; 

} 
else{ 
out[pos]=in{[t]; 
post+; 
} 
} 
out[pos]=0; 
return out; 


[/PSSESSSESSSSS SSS SSSES SSS SSK SSSS SHES SSSSS ES SSES SSS SESS / 


#include <windows.h> 
#include <stdio.h> 
#include <io.h> 
#include <winsock.h> 
#include “routines.h” 


Pha Saad Sala he Sicha hale Sal dina oad ha ach det ad nd nnd Nata dd dal ali 
SSTSSSSSSSSSS SSS SS SSS SS SSS SS SSS SSSS SS SSS / 


long GetFileTime(LPCSTR filename,FTIME * ft){ 


FILE *fptr; 
int rt; 


/* create a file containing 10 bytes */ 
fptr = fopen(filename,"r’); 


rt = getftime(fileno( fptr),( ftime* )ft); 


/* close the file */ 
fclose{fptr); 


if(rt 0) 
return TRUE; //success 


return FALSE; 


[PFFSSSSS SSS SSSES SSS SSS SSS SSS SESS SSSS SS Ss 
SESE ST SSeS SSSA SCRE SEES ES ETS V ES ST ESS SSS] 


long GetFileSize(LPCSTR filename) { 


FILE *fptr, 
long size; 


/* create a file containing 10 bytes */ 
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fptr = fopen(filename,"r"); 
size = filelength(fileno(fptr)); 


/* close the file */ 
fclose(fptr); 


return size; 


} 


/PSSSSSSSSS SSS SHES SHES SSSSS SSS HEHHEEHE SEE 
ee SC SSSSSSSSSHS SESS SES SSESESSSSESSE SS / 


int FixFilename(LPSTR filename) { 


int tx; 
int len = Istrlen(filename); 


for(t=0;t<lent++) { 
if( filename[t}—’/){ 


} 
} 


/icheck for two in a row 
for(t=0;t<len;t++) { 
iff filename[t}—'W’){ 


filename[t]='W’; 


if{filename[t+ | J—'\W'){ 
for(x=t;x<len;x++){ 
filename[x] =filename[x+1 }; 
} 


SOFSSSSSSSSSSSHSSSHSSSSSSSSS SSS SSSSSSHEH SESE SEES SEKESE 


return 
0 - success 
1 - address string is not long enough 
2 - failed 


PSSSSSSSESSTSESSSHSSSSSSSSSTSSOSSSSSSSSHAAESSSEKSESSESES SF / 


int GetClientAddressFromName(LPSTR address,int maxaddrlen,LPCSTR name) { 


hostent *pHostent; 
int len; 


pHostent = gethostbyname (name); 


if(pHostent==NULL) 
return 2; 


& 
len = lstrlen(pHostent->h_addr_list{0]); 


if{(len > (maxaddrlen-1)) 
return |; 


istrcpy(address,pHostent->h_addr_list{0]); 


return 0; 


/PSSSHSSSSSSSSSSSSSSSSSSSSHHATSESSHSSSSSSSSHSTSHSESSESS 


0 - success 
1 - address string is not long enough 
2 - failed 


SSSSCSSCHRAESSSSSSSSSHSSSSSSSHSSHSHHSSSSSHHKESHSSS SSS S SSS / 
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int GetClientNameFromAddress(LPSTR name,int maxnamelen,LPCSTR address) { 
unsigned long addr; 
hostent *pHostent; 
int len; 
addr = inet_addr (address); 
pHostent = gethostbyaddr((char* )&addr,4,PF_[NET); 


if(pHostent—=NULL) 
return 2; 


len = Istrlen(pHostent->h_name); 


if(len > (maxnamelen-! )) 
return 1; 


Istrcpy(name,pHostent->h_name); 


return 0; 


[AASSSSSSSSSSSSSETSESSSSSSSTTETSETSSSSSSESHSSSSVSSSSSEVSS FHSS SSVS & / 


SAMPLE DATA FILE USED IN DEMONSTRATION IS CALSSIFIED AND 
CAN NOT BE INCLUDED HERE 
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